Granting access rigths to local servers by using AD groups

A small project just came along. Access to Windows servers had to be restricted by user groups. Two types of users should be served: those needing admin rights, and those needing RDP permission. Management should be done from a central location (= Active Directory).

I wrote a simple script that does the following:

  1. Harvest all Windows servers, filtered by name
  2. For each server, check whether Active Directory groups for permissions (Admin and RDP) already exist
    1. If so, do nothing
    2. If not
      • create the Active Directory Groups in the right OU
      • add the AD Groups to the local groups of the specific server. In my case: local group “Administrators” and local group “Remote Desktop Users”


Read More

How to resolve SCCM Offline Servicing: Failed to apply one or more updates

I’ve been using the RTM-iso of Windows Server 2012 R2 for OS Deployment for a few years now. Everything was working fine, although the update installation part was getting time-consuming. I decided to slipstream all updates using the built-in Offline Servicing feature in SCCM. However, I ran into the error “Failed to apply one or more updates”.


To troubleshoot this issue, we examined OfflineServicingMgr.log (located on your Site Server in the System Center Configuration Manager install directory):

I quickly identified the problem: the previous attempt to update the WIM-image had failed, and the DISM-process was unable to unmount the image. To resolve this issue, I opened an Command Prompt and ran the following command:
dism.exe /cleanup-wim
This command succesfully unmounted the image. From this point, I could re-schedule the updates for the WIM-image in SCCM.

Read More

SCCM, batch files, and 32-bits processes on 64-bits OS

Today I was (again) confronted with the annoying System32-on64bit-OS situation.
To enable the Disk Cleanup Tool on Windows 2008 (R2), I had to copy 2 executables from the source location to C:\Windows\system32\*
I created a batch file, containing 2 lines:

copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe C:\Windows\System32\cleanmgr.exe
copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63\cleanmgr.exe.mui C:\Windows\System32\en-US\cleanmgr.exe.mui
Manually running the batch file on the server works fine: As long as I ran the batch elevated (as administrator), the files were copied to the target location. However, when executing the batch file from a package in SCCM, nothing happened. This issue is related to the fact that the SCCM client is a 32bits process running on a 64bits OS.

The solution is easy… Once you know it. :)
Use %systemroot%\sysnative\cmd.exe to execute the commands.
More information about Sysnative:
More information about cleanmgr:

I ended up creating a package in SCCM, referring to a batch file cleanmgr_W2008_R2.bat

%systemroot%\sysnative\cmd.exe /c copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe C:\Windows\System32\cleanmgr.exe
%systemroot%\sysnative\cmd.exe /c copy C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63\cleanmgr.exe.mui C:\Windows\System32\en-US\cleanmgr.exe.mui


Read More

Solving an uninstall problem: Source is invalid due to missing/inaccessible package.

This blogpost describes a method I have used to uninstall Flash 19, when the original source files on the local computer are missing. Although all file names and values are specific to Flash 19, the overall method is generic. So if you have problems with uninstalling a software product because of missing sources (error 1706 : -2147483647 ), continue reading! :)

During an upgrade action of Flash %old% to Flash, the majority of our desktops would not upgrade to this latest version. To find out the reason for not uninstalling the old version and installing the latest, I used the following command:

The verbose logging led me to the conclusion the source was missing of an older Flash version. In a standard situation, the source files are located in %windir%\Installer. However, for some reason, now they were not. The source location was the ccmcache folder: C:\WINDOWS\CCMCache\%%\. This folder didn’t exist and therefor uninstallation could not take place.

Luckily, I had the original MSI’s located on my SCCM Distribution Point. I ended up creating a script with some registry modifications. The summary of the script was as follows:

  1. copy MSI files from network to local folder c:\windows\ccmcache\flash\
  2. Query the MSI Product Code of Flash 19 to check whether  Flash 19 is present on the computer,
    1. If present, then import registry key that sets the MSI source location to c:\windows\ccmcache\flash\
    2. Else, skip uninstall and go to install Flash 20
  3. Uninstall Flash 19
  4. Install Flash 20

The batch file contained this commands:

To create the file “install_flash_player_19_active_x_19.0.0.226.reg”, it’s best to open your Registry Editor and navigate to the [HKEY_CLASSES_ROOT\Installer\Products\%ID_of_product%].  Edit 2 values that contain the source location:

  1. HKEY_CLASSES_ROOT\Installer\Products\C71265EE9F3BB2044BCE360F095FD1D3\SourceList\LastUsedSource
  2. HKEY_CLASSES_ROOT\Installer\Products\C71265EE9F3BB2044BCE360F095FD1D3\SourceList\Net\1

Export the complete registry key, and strip it until only your modified entries are left over. For example, in my case the registry file contained the following text:

This registry file can now be used to import into every computer suffering the upgrade failure.

(*) Note that msiexec /x “install_flash_player_19_active_x_19.0.0.226.msi” is not sufficient, because Windows would still look for the original source location, rather than using the given path to the existing MSI file. You must change the source location in the registry to successfully uninstall.

Read More

Error GetDirectoryList_HTTP mapping original error 0x80072ee7 to 0x800704cf in SCCM 2012

Another day at the office, I noticed one client had problems downloading packages. In Software Center, the specific package stalled at “Downloading (0%)”. A closer look at the logfiles of the client led me to the following errors in DataTransferService.log

Usually, this error indicates port blocks on port 80 and 443. You should then try to temporarily disable your firewall or open port 80 and 443 to your distribution point server. In my case, however, the firewall was already disabled. The DP was on the same subnet, so no hardware firewall either.

TO make sure the DP was working correctly, I copied the http address from the logging, and entered it in Internet Explorer a random server



When I entered the URL the same on the faulty server, I got a “Page could not be displayed” error. So, there really was no communication possible on port 80.

Next step was a tracert to the sccm server. It timed out at the second hop. This turned out to be the problem. The faulty server had two NICs configured: 1 for normal traffic, 1 for management traffic. The Management NIC was configured with a wrong subnet.











After fixing the network settings at the client, and a restart of the SMS Agent Host service,  content downloading continued :)


Read More