Bringing Clients Online: Software Update-Based Installation

When it comes to deploying the client to domain-joined devices, you’ve got a few choices. Software Updates, Client Push, or custom script. Deploying via software updates is definitely my preference, as any machine joined to the domain will get the SCCM client package pushed via the WSUS server the client device is pointed to via GPO.

Assuming we already have a healthy SCCM environment with a Software Update Point role somewhere, it’s a straightforward process. For proper usage of this client-deployment strategy, you’ll also want to verify that you have extended your AD schema, published your site to your AD forest (from SCCM console), and created at least a single boundary and boundary group configured to be used for site assignment. Else, your clients will not find a source from AD for the package nor a site code/MP to be assigned to during install.

You need to publish the client package to WSUS through the console. It generally will take a few minutes before both version boxes populate.


Next, you’ll need to configure a GPO to point targeted machines to WSUS. Be sure to include the port designation in the path, else you’ll likely see errors in the Windows Update checking process once the client processes the new GPO. Ask me how I know.

You can hop on a targeted system, run “gpupdate”, and verify that this policy applies with gpresult. Opening Windows Update and clicking “Check For Updates” should show that updates are “being managed by your administrator”, and if all goes well- you should have one update available, that update being the SCCM client package.


Once these steps are completed, you’ll have live and active clients to manage, and they’ll receive their Windows Update items through Software Center alongside your other SCCM deployments.


Some guidance on Software Update Points

I’ve heard some confusion, especially from people who are just starting to implement Configuration Manager in their environment, over the SUP role and how it looks in practice.

Obviously, you’re under no obligation to use the WSUS integration or Software Updates functionality in SCCM. You can continue to use your standalone WSUS, but in the eyes of a user, I’d much rather find my Windows Updates in the same place and being deployed with the same constraints as other applications and packages being released for my machine.

When you add the WSUS role to your target server, you’ll want  to complete only the initial configuration window where you’re asked where to store the updates content. Don’t proceed with the next bit, which will have you choose classifications and such. All of this is to be done within the console. The last time I did a rebuild, with v1607, I found that I had to perform a manual synchronization with Microsoft Update once after adding the role.

Once that’s done, you can add the Software Update Point role to your site server in the console. In my last corporate environment, this process was repeated for the CAS and three primary sites. The primary sites were configured to synchronize with the CAS, so essentially, CAS communicated with Microsoft Update and notified downstream/child servers when it retrieved new items. The idea here is that your WSUS database is complete, and then you can narrow down product selection and update classification from the SCCM console.  This is done during the addition of the Software Update Point role.

It’s a good idea to enable the WSUS cleanup tasks (I have had to deal with the results of not doing this), as well as enable alerts on synchronization failures so that you can be sure that the SUP is successful in what should be a mostly-automated process when you’re done, with the help of automatic deployment rules.

You should get an understanding for the entire process from CAS Microsoft sync to client experience before you implement this in production. You’ll want to lay down your intended Sync schedules, Software Update Groups, ADRs, target collections, available/deadline preferences, and probably create staggered deployments to allow a “beta” group to receive updates prior to being dropped into full production.

Is your SCCM installation taking ages in a Hyper-V guest?

Rebuilding the SCCMChris lab as time permits, I ran into an issue during installation of tech preview v1703 — the installer would hang during the database setup for many, many hours. It didn’t seem to completely stall, but after a day, installation was still chugging along. Thankfully, there’s a simple solution! For your guest machine, disable “Dynamic Memory” in Hyper-V manager, uninstall the site to reverse your failed installation, then kick it off again.

Implementing Microsoft’s Local Administrator Password Solution

Many environments I’ve worked in fall into the same habit. They set the same local administrator password on all client systems across the domain and rarely, if ever, reset it. When you consider the number of ex-employees that have that password and knowledge of the fact that all non-servers sometimes use it, coupled with the potential for Pass-The-Hash attacks, you see quickly why Microsoft created the Local Administrator Password Solution. It’s really easy to implement. Easy enough that the documentation alone will probably get you there. Regardless, here’s my guide for implementation. As usual, your mileage may vary.

On your system, you’ll need to install the LAPS package with the management tools component to have the appropriate PS cmdlets and GPO template.
Download LAPS here:

Choose to install management tools (and GPO extension if you intend to apply LAPS to the system you’re working from)

We need to accomplish 5 things to successfully deploy LAPS. Adjust paths as necessary, mine used as an example. I would suggest going through all of the motions with a test OU and a couple of test systems before deploying to a broad range of systems.

1. Extend the AD schema. This is a forest level change and cannot be reversed.

Import-Module AdmPwd.PS

2. Allow computers in target OU(s) to update their password fields.

Set-AdmPwdComputerSelfPermission -OrgUnit “OU=Computers,DC=sccmchris,DC=com”

3. Allow specific users to retrieve the content of password fields for computers in target OU(s). Here, let’s assume we have a group called “Desktop Support Staff” and we’d like members of that group to be able to retrieve local admin passwords for any system within the Computers OU.

Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Computers,DC=sccmchris,DC=com" -AllowedPrincipals "Desktop Support Staff"

4. Configure GPO and link to appropriate OU. Below is my configuration. Note: Until you enable the setting “Enable local admin password management”, regardless of extension install or GPO application, nothing will be changed in re: to local admin password. If you leave “Name of admin account to manage” not configured, it will manage the default Administrator account. This is nice because you can roll the client MSI in advance of actually enabling LAPS.


5. Deploy LAPS CSE (client side extension) on target systems. This is the same MSI that you used to install the management tools. If you run this MSI with the silent switch, it will install only the GPO extension for the client (no management tools). This makes it incredibly easy to deploy in SCCM or you can even script it on non-SCCM clients.

Only once a client has the GPO extension installed, the GPO applied, and the “enable local admin password management” setting enabled, the management will begin.

That’s it. You’ve deployed LAPS. Of course, you’ll want to do some auditing to ensure systems are successfully submitting their passwords. Options for reading back local passwords: 

1. The MSI’s management tools component includes a LAPS UI for retrieving local admin passwords and forcing resets.

2. I use a LAPS Password plugin for SCCM. Find it here:

3. PowerShell option:

Get-AdmPwdPassword -ComputerName W10L1234

4. You can retrieve the passwords for *all* computers in an OU (assuming you were granted Read). This is especially useful for your initial test deployment and verifying passwords are being submitted (accurately):

Get-ADComputer -Filter * -SearchBase “OU=Computers,DC=sccmchris,DC=com” | Get-AdmPwdPassword -ComputerName {$_.Name}


I had very few issues with this deployment. If I could give you one piece of advice it’d be to use options #4 to generate a list of systems that have submitted a password and compare it to a list of computers that have supposedly installed the client side extension already. Troubleshoot the delta. The few systems I had trouble with were generally experiencing group policy application issues. I had two systems (out of 1,000) that required manual reinstalling of the CSE.

PS App Deployment Toolkit: User Logged On / Off Deployment Types

I started using PSADT a year or two ago for my commonly updated applications. Flash, Java, Reader, etc.

One of the first issues I encountered was having a single deployment type. Per PSADT documentation, your deployment type should be deployed with “Allow users to view and interact with the program installation” ticked. Unfortunately, if you set “Logon Requirement” to “Whether or not a user is logged on”, this field greys out, unticked.

So, with this box unticked, PSADT proceeded in Noninteractive mode. Instantly closing Internet Explorer and whatever other apps I had specified. This didn’t make me (or anyone else) happy.

My workaround is quite simple. I have two identical deployment types with different User Experiences. Additionally, I have created a Global Condition to determine whether the workstation is currently in use or not (whether locally or via RDP). This Global Condition is set as a requirement on each Deployment Type.

You can create the Global Condition under Software Library -> Global Conditions. I named mine “Workstation in Use”. The discovery script is incredibly simple:

[bool](query user)

On your “User Logged On” deployment type, configure as such:
User Experience Tab
Installation Behavior: Install For System
Logon Requirement: Only when a user is logged on
Installation Program visibility: Normal
Tick the Allow users to view and interact box.
Requirements Tab
Add -> Custom -> Condition -> Workstation In Use -> Value -> Equals -> True

On your “User Logged Off” deployment type, configure as such:
User Experience Tab
Installation Behavior: Install For System
Logon Requirement: Only when no user is logged on
Installation Program visibility: Normal
The “Allow Users to View and Interact” will be greyed out automatically.
Requirements Tab
Add -> Custom -> Condition -> Workstation In Use -> Value -> Equals -> False

This setup will allow you to give your users the PSADT experience, but also leverage PSADT (in noninteractive mode) to perform installations while no users are logged into the system(s).