Friday, December 16, 2016

Automatic Removal of software in SCCM (Link to other Blogs)

This is more of a reminder for myself, but wanted to share with you a couple of blog posts that can help you with automatic software management using Software Metering with SCCM.  If you have Orchestrator in your environment you can take things a step further and do cool things like automatic approvals based on license count and approval cancellation after a specific time.

System Center Dudes:

Neil Peterson - System Center Premier Field Engineer

I have been using the SCCM/SCORCH method in my environment for a few years now and it works great until recently .. had to scramble to find these posts so that I could fix a mistake that was made.


Wednesday, November 30, 2016

Time display issue in Windows 10 1607 after in-place upgrade

Wow, it has certainly been a long time since the last time I've posted on this blog!  While I keep promising to post more, chances are I'll get busy again and won't have time to post .... which is the perfect segway to todays topic:  TIME!

Lately I've been designing a company-wide migration to Windows 10 1607 using the in-place upgrade option with System Center Configuration Manager Current Branch.  One issue that came up was time ... or rather display time ... being WAY off (and by way off I mean hours, up to 3 hours in some case).

Now you may be thinking "But Terry, doesn't that mean your users can't log in?" ... and the answer is .. well .. no!  See, the issue being experienced only affects the time that is displayed on the system tray and lock screen, not the system time.  System time is critical for domain-joined systems as if you are off by more than 5 minutes, you can't authenticate with AD, so the default behavior is workstations sync time with your local Domain Controller or the PDC Emulator.  System time is done in UTC, and Display Time is UTC +/- your time zone offset.  This means that it is technically possible for time to be correct and incorrect at the same time!

How to tell if you have this problem

  1. Open Windows PowerShell (right-click Run As Administrator, you will find out why later)
  2. Type this command:  w32tm /query /peers
If time is configured correctly then it should be pointing to a local Domain Controller or the PDC Emulator.  Note that if you have specific group policies around workstation time configuration, then you will need to make sure that it matches.  In the case of an affected machine, it will show the following: (i'll post a screenshot shortly)

State: Pending
Time Remaining: (up to 24 hours, in seconds)
Stratum: 0

In my case I have systems spread out over multiple time zones.  In some cases the time displayed properly but it was not syncing from the local DC.  In other cases the display time was out by up to 3 hours!.

How to fix the problem

You still have that PowerShell window open right?  Here are the commands you need to run (in order):

  1. Stop-Service w32time
  2. w32tm /unregister
  3. w32tm /register
  4. Start-Service w32time
  5. w32tm /resync
Once finished you can run w32tm /query /peers again.  If you see something like this, then you are good:

I put these commands into a PowerShell script and put it at the end of my in-place upgrade Task Sequence in Configuration Manager:

And there you have it!  What do you think?

Wednesday, July 1, 2015

Automating Office 365 Updates in SCCM with Powershell!

Hello everyone!  It has been way too long since the last time I posted here, something I hope to rectify.  Today I would like to talk about Office 365, specifically the Office Click-to-Run package and how you can automate updates in a more controlled manor using PowerShell and Group Policy!

For those who do not know, there are two ways to install Office on your system when you are licensed through Office 365.  There is the standard MSI version that you know and love (if your subscription level allows), as well as the new "Click-to-Run" method, or C2R for short.  C2R is really neat since it is basically a self-contained App-V package that doesn't require the full App-V experience installed on your system.  The biggest benefit (or frustration) of C2R is that the update mechanism changes which allows updates to come in faster ... but it does not use traditional methods such as WSUS or Windows Update.

A bit of back story, at my company we recently deployed Office 365 out to everyone and made the decision to let updates stream automatically from the web.  According to documentation systems should only download the delta difference between the current version and the previous version, so the update traffic shouldn't be too bad.  In hind-sight, this was a terrible idea for a couple of reasons.  The first reason is that we have just shy of 1000 systems/O365 licenses so the sheer number of systems weren't taken into account.  The second is that for some reason, all of our systems decided to download the ENTIRE OFFICE INSTALL instead of just the delta.  To make matters worse, all of this download traffic started on a day that we launched a user outreach program which focused on training and implementation of the Modern Workplace (i'll post about that another time).

So, on to the fun bits.  How we solved our updates issues:

Basically, I wrote a PowerShell script that does the following:

  1. Deletes the current Office 365 Install Source from SCCM Server and from a Shared Network Location
  2. Downloads the latest version of Office 365 and copies the content to a Shared Network Location
  3. Connects to SCCM Database
  4. Updates the Application Version to the version being deployed
  5. Updates Distribution Points with the latest Office package
For the Shared Network Location we are using a path that is replicated to all of our offices so that the actual update happens locally and not streaming over our WAN.

Here is the PowerShell Script with comments:

#  Here you are only removing the "Office" folder inside your source package.  Don't remove the parent folder which has Setup.exe and your XML files, you can reuse these.  For your Shared Network Location you can delete everything.  This assumes that you are not specifying a version in your XML file

Remove-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Recurse
Remove-Item -Path "\\SharedLocation\Path\Office365" -Recurse

# Downloads New Office 365 Content based on your XML and waits until the download is complete

Start-Process setup.exe -WorkingDirectory "\\SCCMServer\PathTo\Office365" -Verb open -args "/download configuration.xml" -Wait

# Grabs the name of the folder that contains the actual office content and stores it as a variable

$a = Get-ChildItem -Path "\\SCCMServer\PathTo\Office365\Office\Data" -Directory

# Copies Office data to your shared network location

Copy-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Destination "\\SharedLocation\Path\Office365" -Recurse

# This line is needed if you are not running your script from your ConfigMgr Server.  The path here is the installation directory of SCCM on your server.  You can also use the installation path for the SCCM console if you wish.  This loads the SCCM Powershell modules so that the rest of the script will work

import-module "\\SCCMServer\Installdir\AdminConsole\bin\ConfigurationManager.psd1"

# Connects to your SCCM Database, where PRI = your site code

Set-Location PRI:

#This updates the Application version number.

Set-CMApplication -Name "Your Application Name" -SoftwareVersion $a

#This Updates your distribution points with the latest version of the Office 365 package

Update-CMDistributionPoint -ApplicationName "Your Application Name" -DeploymentTypeName "Your Deployment Name"

There you have it!  I'm sure many of you are asking "Why am I deleting everything before downloading?" and the answer is simple:

When you download the Office 365 deployment it creates a folder under Office\Data with the new deployment version, and will not remove the old one.  Deleting the old version ensures that your Office deployment package doesn't contain any stale information.  Also, the script runs on the assumption that there is only one folder inside Office\Data, and uses that to update the SoftwareVersion later on.

Here is the script without all the comments:

Remove-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Recurse
Remove-Item -Path "\\SharedLocation\Path\Office365" -Recurse

Start-Process setup.exe -WorkingDirectory "\\SCCMServer\PathTo\Office365" -Verb open -args "/download configuration.xml" -Wait

$a = Get-ChildItem -Path "\\SCCMServer\PathTo\Office365\Office\Data" -Directory

Copy-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Destination "\\SharedLocation\Path\Office365" -Recurse

import-module "\\SCCMServer\Installdir\AdminConsole\bin\ConfigurationManager.psd1"
Set-Location PRI:

Set-CMApplication -Name "Your Application Name" -SoftwareVersion $a
Update-CMDistributionPoint -ApplicationName "Your Application Name" -DeploymentTypeName "Your Deployment Name"

Tuesday, July 16, 2013

SCCM 2012: Maintenance Windows and Business Hours

We all know by now that System Center 2012 Configuration Manager is a client-centric product.  Meaning that, while it gives us admins some power over the system to perform certain tasks, the user is ultimately in control of their device.  One way this is acheived is by the inclusion of "Business Hours" on the client.

I'm not going to go into too much detail on how Business Hours works along with Maintenance Windows, instead please see this wonderful blog post from the MS Server and Cloud Platform Team:

Basically, regardless of the Maintenance Window the power is truely in the hands of the end-user for mandatory deployments.  Lets say, for example, that you have an OOB patch that must be pushed out immediately ... soo immediate that you bypass your maintenance windows in order to do it.  If the time is within the Business Hours of the machine (by default its 5AM - 10PM) then the user gets to decide if the installation happens immediately, or if it posponed.

Depending on your patch deployment framework, this can have some serious rammifications if your maintanence windows don't jive properly with Business Hours.  Whats worse is that since Business Hours is a client-side ONLY setting, you can't set this via the ConfigMgr console.

- BUT -

You CAN set this via VBScript or via PowerShell.  Rather than rinse/repeat, here are links to two blogs that outline how to do this:

VBScript (Piped through Google Translate)


Given the nature of this I would suggest applying this script at logon to ensure that all systems get updated with an appropriate time.  It should also be added to your Task Sequence so that reimaged systems start with the adjusted Business Hours.

Have Fun!

Friday, July 12, 2013

How to Configure TimeZones dynamically during Imaging (Take Two!)

A few years ago I had posted what I "THOUGHT" was a method to resolve the TimeZone issue that many of us struggle with but it turned out that not only was I completly wrong, but I was actually barking up the wrong tree!

TimeZone configuration can be a major headache when your enterprise spans multiple timezones, or multiple countries, if you are trying to keep your imaging strategy basic and easy to maintain.  I'm not a huge fan of splitting imaging into numerous collections with each collection given their own Task Sequence Variable to identify TimeZone since that just takes too much work, and I'm lazy!  Up until now I have been just dealing with imaging in one TimeZone then manually adjusting based on the region, totally not efficient!

I came across this excellent blog post which explains it quite well:

Basically, rather than rely on a TS Variable, instead use a VB Script at the end of your Task Sequence that will automatically adjust the timezone based on the DHCP server it is connecting too.  As the blog states, the account used to run this script needs to have read rights to the registry on the DHCP server, but it works qutie beautifully.

Check it out!

Friday, June 28, 2013

Fix: Unable to update User GPO via gpupdate

Group Policy issues are always a pain in the but, I've found.  This one was particularly annoying because of the impact that it had on the user.  The user was unable to access his personal drive on our server (G:\ Drive) as it would not map it during login.  Also, what he didn't mention, the system takes up to 5 minutes to log in.

At first I was strictly working on the drive map issue ... out of 3 network drives that he should get he was only getting one.  Manually running the login script seemed to clear that up temporarily but not permanently.  I then decided to do a GPO update (gpupdate /force /wait:-1) but it threw up an error.  In the System Event Log, I saw this:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F\}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

Since this was the only system on the network having this particular problem, I wasn't convinced that the issue was limited that computer and ... since it was late in the day ... was just going to reimage the box and be done with it.  I decided to check the Details tab for this particular event and noticed something rather peculular:

+ System

- Provider
[ Name] Microsoft-Windows-GroupPolicy
[ Guid] {AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}
EventID 1058
Version 0
Level 2
Task 0
Opcode 1
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2013-06-27T23:33:35.377468900Z
EventRecordID 65946
- Correlation
[ ActivityID] {E6ACB131-AEEC-45A4-98D7-118272AA0081}
- Execution
[ ProcessID] 428
[ ThreadID] 3744
Channel System
- Security
[ UserID] S-1-5-21-2823908405-3494369649-3172151183-3327

- EventData

SupportInfo1 4
SupportInfo2 816
ProcessingMode 1
ProcessingTimeInMilliseconds 16864
ErrorCode 1317
ErrorDescription The specified account does not exist.
DCName ServerName.domain.local
GPOCNName CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=local
FilePath \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

Since I knew what stage the GPO was failing at (applying User Settings) and I knew what was able to complete successfully (applying Computer Settings) I think I figured it out ... and it was a nice easy fix:

Re-create the User Profile on the local machine!

To test I logged the other user out and logged in as myself and noticed that there were no GPO issues under that account.  Then I did the following:

  1. Restarted the PC and logged in as local administrator (you can use any account with admin rights as long as its not the affected account)
  2. Go to C:\Users\ and back up the users content.
  3. Right-Click Computer and select Properties
  4. Click Advanced System Settings
  5. On the Advanced Tab, click Settings under the User Profiles heading
  6. Click the Profile you wish to delete, then click delete
I should point out that at this step I received an error regarding the deletion of the Profile.  I had to hit Delete a 2nd time to remove it from the list, but it didn't actually delete anything ... solidifying the determination that the local user profile is at fault.  I continued on and did the following:

Deleted the profile store manaully (C:\Users\
Launched Regedit
Went to HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

**Take care when editing the registry as you can cause major system damage if edited incorrectly, resulting in a reinstalltion of Windows.  Only proceed with working in the registry if you are comfortable

Within this key I deleted any sub-keys related to the damaged user profile.  You can discover this by clicking on each sub-key and looking at ProfileImagePath to see if it matches the username.  Also, delete any keys that reference TEMP.  After that, restarted the computer and allowed the user to log in locally ... GPO issue resolved!

Friday, April 19, 2013

Fix: Unable to make a bootable USB stick via the USB/DVD Tool or Manually

NCIX had a great sale on a while ago for some inexpensive 32GB USB 3.0 flash drives so I just had to pick up 3.  After all, I try to travel around with a full set of device drivers, various software tools for troubleshooting, and a bootable WinRE stick just in case.  Imagine my surprise when I went to create a bootable USB stick with Server 2012 when I came across this error:

"We are unable to copy your files.  Please check your USB device and the selected ISO file and try again"

I thought that I had a bad USB stick, so I moved on to the next one ... same thing ... the THIRD one ... same thing!

I left it on the side-burner for a while but today really needed to do some manual server installs.  Came across this excellent post by Devin which outlines the fix (THANKS DEVIN!)

If you don't feel like clicking through to Devin's site (its excellent btw), here are the nitty gritty steps you need to do:

  1. Connect the affected USB stick
  2. Open either CMD or PowerShell (I really need to work more in PS)
  3. Run Diskpart
  4. Type List Disk to bring up the list of current disks on your system
  5. Type Select Disk x where x = the disk number for your USB stick
  6. Type Clean to clear the configuration of that USB stick (Caution, make sure you don't have any files on there that you need as this will erase everything)
  7. Type Create Partition Primary to create a new partition
  8. Type List Disk to verify that the new partition is made.  If you see an offset of 1024KB then the fix worked
  9. Type Exit to close diskpart, then disconnect the USB stick from the system
  10. Plug it back in, it will ask if you wish to format the USB stick, say Yes or Format
You should now be able to make a bootable USB stick!

From what I can tell, this has something to do with how the USB stick was partitioned at the factory.  Maybe it was created without Windows in mind ?