Oh hey there.

It's been a while since I've done anything useful with this site, so I'm making myself a late new year's resolution to start writing content again.

For the last few months I've spent a lot of time educating and reskilling myself in the area of DevOps (or ProdOps). I find practical projects are a great way to learn, so I set myself the task of retooling my home lab to accommodate both VMs in Windows (Hyper-V) and containers in Ubuntu Linux (Docker / Kubernetes). This gives me the flexibility to stand up any environment I might need:

• Reproduce customer issues
• Evaluate products / software
• Reduce the time taken to learn something

The last is a big one for me. How many times have you been put something on the backburner because it would require you first set up a dozen prerequisites? Containerization has mostly solved this. For example, you wanted to set up a Graylog server? Cool, have fun setting up ElasticSearch and MongoDB first. OR, just use a docker-compose to stand up the whole lot in around 10 seconds. Anyway, I disgress...

This site was being hosted on Wordpress, on a seriously underperforming linux VM that I had limited access to. After a bit of research, I opted to move to self-hosted on Ghost, on my home lab. I have a slew of services I was running on a Windows server which would be much more performant in a containerized environment - so adding Ghost to that list wasn't that big a deal. After that, I manually migrated a few blog entries but ultimately opted to trash most of the content and start from scratch.

This site is now running alongside 13 other services in Docker Swarm on my home lab, behind a reverse proxy, each with enforced SSL and a valid certificate from LetsEncrypt. The performance is stellar in comparison to Wordpress, and I can easily stand up new VMs or containers without interference to the existing services.

I want to work on building an ARM based Kubernetes cluster using Terraform and Ansible to provision and configure the whole thing. First, I need to buy myself some hardware though. Once I start the process, I'll document and add some new stuff here.

SCCM 2012 gives the option of installation an application as the currently logged in user, or as the LocalSystem account. There are differences in why you would choose one over the other – namely, easy access to current user paths and registry keys. Some Windows Installers have a lot of Per User components and if installed using LocalSystem, tend to be a pain in the ass to get installed when an actual user logs in. So running deployments as the currently logged in user can be very handy.

However, there is a limitation in the Application Model whereby if you chose to install an application as a User, it inherits their user privileges for the installation. This is a problem if your users are Standard Users as opposed to Local Administrators – more often than not, you won’t have the permissions to perform a full install.

If you’re lucky enough to have deployed BeyondTrust Defendpoint (formerly Avecto Defendpoint / Privilege Guard), you can very easily overcome this by granting Administrator Privileges to PSAppDeployToolkit installation scripts. Here’s how I have this working.

I created two Application Groups, and one Work-Style in Defendpoint. The first App Group is for the SCCM Agent:

The second App Group is for the Deploy-Application.ps1 scripts themselves. It is set to match child processes of the first App Group. You can make this more secure by using a wildcarded path such as “%WinDirCCMCache*Deploy-Application.ps1”. Better still, ensure you code sign your Deploy-Application.ps1 scripts and add a match criteria against the Publisher:

Finally, the Work-Style is set to automatically add Admin Rights to any Deploy-Application.ps1 that gets run – provided it is a child process of the SCCM Agent. This ensures the PSAppDeployToolkit installation script only gets Admin Rights when called by the SCCM Agent:

And that's all there is to it :)

Edit: Hey! We just made this obsolete with v3.6.1 of the toolkit. It’s all in-built now! 🙂

One of the primary goals of the PowerShell App Deployment Toolkit is to simplify complex scripting operations to deploy applications. It does however, require that you know PowerShell to some degree, even though a lot of the in-built functionality is going to shield you from a lot of the complexity. This applies to even the most basic of installations. You’re going to need to populate the template provided with a few basic details.

I wanted to see if I could remove the need for any editing of the provided template. What I’ve come up with will be really handy for PowerShell beginners looking to evaluate the toolkit’s functionality, and allow you to rapidly create an application deployment. To that end, I’ve created a customized version of the template which does the following:

• Searches the Files subfolder for a Windows Installer installation (MSI) and any custom transform
• Pulls Windows Installer properties from the MSI file and uses them for the deployment
• Prompts to close any applications specified with the -CloseApplications parameter if they are open
• Installs / Uninstalls the application

How to use the dynamic Deploy-Application.ps1:

• Download a copy of the toolkit from here
• Overwrite Deploy-Application.ps1 with this version from here
• Drop your MSI (and MST if you have one) into the Files subfolder
• Create a new SCCM Application / Package with these source files
• Include the -CloseApplications parameter if needed, e.g. - Deploy-Application.exe Install -CloseApplications “iexplore,firefox,chrome”
• Deploy-Application.exe Uninstall -CloseApplications “iexplore,firefox,chrome”

The benefits of using the toolkit without any customization are still quite apparent:

• Consistent user experience for closing applications and displaying installation progress, all localized in numerous languages
• Logging of all Windows Installer install / uninstall operations, as well as logging from the toolkit itself
• Integration with SCCM 2007 / 2012 in terms of exit codes, reboot suppression and fast retry

I’ve been meaning to start posting some tutorials for a while and I’ve finally gotten around to my first. So here goes…

Intel VT is a requirement of any VM solution (Hyper-V, VMware, Virtualbox etc) as well as a number of emerging security products such as McAfee Deep Defender. By default, Lenovo hardware ships with Intel VT disabled in the BIOS. If you’re a large enough enterprise, you can probably agree to have this enabled in the BIOS from the outset but for smaller companies this can be costly. Luckily, you can access Lenovo BIOS settings using WMI. It’s fairly simple to put together a VBScript to enable this as part of your  OSD process. But what if you already have your machines deployed and need to make the change post-deployment?

Well, a nice way of handling this is to use an SCCM Configuration Baseline to enforce the setting. And I’m going to walk you through how to do it…

First, we’re going to open SCCM > Assets & Compliance > Compliance Settings > Configuration Items and create a new Configuration Item:

You’ll only want this running on client OSes so deselect anything server:

Create a new Setting and populate as follows:

• Name: Intel Virtualization Technology Configuration
• Setting Type: Script
• Data Type: String
• Discovery Script – Type: PowerShell:

gwmi -class Lenovo_BiosSetting -namespace rootwmi | Where-Object {$_.CurrentSetting.split(“,”,[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][StringSplitOptions]::RemoveEmptyEntries) -eq “VirtualizationTechnology”} | Format-List CurrentSetting

• Remediation Script – Type: PowerShell:

(gwmi -class Lenovo_SetBiosSetting -namespace rootwmi).SetBiosSetting(“VirtualizationTechnology,Enable”)
** (gwmi -class Lenovo_SaveBiosSettings -namespace rootwmi).SaveBiosSettings()**

Create a new Compliance rule for this Setting as follows:

• Name: Intel Virtualization Technology Compliance Rule
• Value: VirtualizationTechnology,Enable
• Check “Run the specified remediation script when this setting is non-compliant”

Now create a second Setting and populate as follows:

• Name: Intel VTdFeature Configuration
• Setting Type: Script
• Data Type: String
• Discovery Script – Type: PowerShell:

gwmi -class Lenovo_BiosSetting -namespace rootwmi | Where-Object {$_.CurrentSetting.split(“,”,[StringSplitOptions]::RemoveEmptyEntries) -eq “VTdFeature”} | Format-List CurrentSetting

• Remediation Script – Type: PowerShell:

(gwmi -class Lenovo_SetBiosSetting -namespace rootwmi).SetBiosSetting(“VTdFeature,Enable”)
** (gwmi -class Lenovo_SaveBiosSettings -namespace rootwmi).SaveBiosSettings()**

Create a new Compliance rule for this Setting as follows:

• Name: Intel VTdFeature Compliance Rule
• Value: VTdFeature,Enable
• Check “Run the specified remediation script when this setting is non-compliant”

When finished, we should be left back in the original Wizard with two Settings and two Compliance items as follows:

Now that our Configuration Item is created, we need to Create a new Configuration Baseline for deployment. Navigate to Assets & Compliance > Compliance Settings > Configuration Baselines and create a new one as follows:

Once this is created, you can Deploy to any collection in either Monitor or Remediation mode. I would suggest Monitor first to get a handle of how many machines will be affected, and maybe start off in Remediation on a handful of machines to ensure it works as expected. Changes to the BIOS take effect when the machine is next restarted.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

So I won’t make any fanfare about this, I’ve made just a few small changes and fixes to WMA as I’ve neglected it for quite a bit.

• Added support for Windows 8 / 8.1 - Copy the amd64 and x86 folders from USMT 5 as subdirectories of the WMA folder, ie.- MigAssist.exe- amd64
• x86
• Fixed issue where maximum migration size couldn’t be disabled
• Fixed issue where progress wasn’t updating correctly
• Fixed issue where Health Check wouldn’t always run
• Removed support for Windows XP (USMT 3)
• Removed branding – looks better with Windows 8 / 8.1 theme

Available on Github here: https://github.com/sintaxasn/MigAssistant

Myself and my good friend Sean Lillis have been working on a neat project for the last few months. Here’s a bit of the blurb:

The PowerShell App Deployment Toolkit provides a set of functions to perform common application deployment tasks and to interact with the user during a deployment. It simplifies the complex scripting challenges of deploying applications in the enterprise, provides a consistent deployment experience and improves installation success rates.

We’ve set up a GitHub project and have published the initial public release, along with some very extensive documentation. Head on over to the link below to take a look!

https://psappdeploytoolkit.com