How to Turn Off Compression in Configuration Manager 2007 Software Distribution

This is a question I’ve been asked a few times. By default, SMS and ConfigMgr both compress package content into a PCK file to distribute the content to child sites. The problem you might run into with Operating System Deployment WIM files, which are already compressed, is that they take forever to move from one site to another, finally to your distribution point.

There is a way to handle the compression and exclude WIM files, as well as any other extension you want to exclude. This can save you a good amount of time. In my customer’s case this week, we noticed that distribution manager took 5 minutes to complete “compression” instead of 30 minutes that it previously took.

I mention “compression” (in quotes) because while distmgr.log will show the file being compressed, if you look at the file size, it’s actually slightly bigger (in some cases) than the original WIM file.

For example, look at this screen shot of my distmgr.log where I send an x86 boot WIM that distmgr compresses

Compressed Package

Notice the first line where it says the size of the package is 129544 KBytes and the compressed size at the bottom is 129068 KBytes. Not very much space gained here, but look at the amount of time it took to compress roughly 130MB. It took 2 minutes.

Let’s take a look at the same package with compression off for WIM files:

Notice here how the same package content is still “compressed”, but the content is actually BIGGER, yet the amount of time is a minute less (or 50% in reduction of time to “compress”). It’s bigger, likely because there is some additional information that gets added to the package as it is getting moved to a .pck file. The package will always convert from a .wim to .pck, however the compression engine simply isn’t involved.

In order to exclude WIM files from compression you need to edit the following location in the registry:

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ SMS\ Compression\ DontCompressExts on 32 bit servers


HKEY_LOCAL_MACHINE\ SOFTWARE\ Wow6432Node\ Microsoft\ SMS\ Compression\ DontCompressExts on 64 bit servers

In this list, you will see:


Simply add


Have ConfigMgr Client Health Problems? Check out the ConfigMgr Client Health and Remediation Services Offering!

Normally I don’t try and sell things on my blog here, however there’s a new service offering that I think many that come across this blog will be highly interested in. I know when I worked as a customer before coming to Microsoft I had to deal with Client Health issues (Client health was actually my full time job for nearly a year) and I would have loved a service like this.

Sometime in September, the ConfigMgr Client Health and Remediation Service offered by the Premier Field Engineering (PFE) group (the group I am apart of at Microsoft) will be made available to all Premier customers. This offering will have an engineer come on site and install our client health solution and offer training on how to utilize it. We will then setup a separate engagement a couple of weeks later to work on remediation (this will allow time for the clients to report back their health state).

If you’ve ever had a CMRAP done on your environment, this is an excellent complement to that offering as the RAP will look at the risk and health of the server environment, however it won’t go into detail about the health of your clients. There’s no requirement that a RAP be done on your environment to leverage our Client Health and Remediation Service, however to get a good idea how things are going, doing both is highly recommended.

If you’re interested in having a Microsoft PFE come on site to look at the health of your SCCM clients, please leave a comment on this post, or send me an email at richbal a.t. You can also work with your Technical Account Manager (TAM), however since this offering is relatively new, they may or may not be aware of it.

For more information on the offering, please see Chris Sugdinis’ blog post.

Fix for Accessing Windows Vista and Windows 7 Administrative Shares (C$, Admin$, etc) – Client Push

This post isn’t exactly just a Configuration Manager fix for Client Push, however it will help anyone who is trying to connect to an administrative share on a Windows Vista or Windows 7 machine that is having problems with “Access Denied” messages even though you know 100% for a fact that the account you’re using is the right one.

User Account Control Remote Restrictions

Starting with Vista, User Account Control introduced some remote restrictions of administrative accounts. You can click the previous link if you want to read up on it. Suffice it to say, to disable these remote UAC restrictions of accounts that are in the local administrators group, do the following:

  1. Click Start, click Run, type regedit, and then press ENTER.
  2. Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
  3. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
    1. On the Edit menu, point to New, and then click DWORD Value.
    2. Type LocalAccountTokenFilterPolicy, and then press ENTER.
  4. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
  5. In the Value data box, type 1, and then click OK.
  6. Exit Registry Editor.
If the machine you’re trying to manage happens to be apart of a HomeGroup (introduced in Windows 7) then you may run into some issues. To leave a HomeGroup:
  1. Click Start, Click Control Panel
  2. Click View by Small Icons
  3. Click HomeGroup
  4. Click Leave HomeGroup
Turn on File and Printer Sharing in the Windows Firewall
If you happen to have the Windows Firewall enabled, you’ll need to make sure File nd Printer Sharing is enabled in the firewall settings:
  1. Click Start 
  2. Click Control Panel
  3. Click Category and select Small Icons
  4. Click Windows Firewall
  5. Click Allow a Program or feature through Windows Firewall
  6. Find File and Printer Sharing and enable Home/Work and Public network

By following the above tips, you should now be able to access any administrative shares that you have proper credentials for, and should also get client push working for some machines in which you are getting access denied or invalid network path messages and/or Failed to get token for current process (5) messages in the ccm.log.

Primary Site Installation Greyed Out in SCCM 2007 SP2 installation?

Had an annoying issue today where the customer and I tried to install a primary server but kept getting stuck with the option to install a primary server greyed out. Turns out we were using the SP2 upgrade media that was used when they were upgrading the SCCM sites in their environment awhile back.

So in short, make sure you have the slipstreamed SCCM 2007 w/SP2 media instead of upgrade media to prevent this bone-headed move :)

Location of SMSTS.log when using Configuration Manager Operating System Deployment

For those using OSD to image, the smsts.log is a valuable log file to help in troubleshooting installation issues of your Windows images. The smsts.log file, however, moves around depending on what phase of the installation you are in. Below is a list of the location depending on where you are in the installation process:

  • Windows PE before HDD format: x:\windows\temp\smstslog\smsts.log
  • Windows PE after HDD format: x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version Windows before SCCM agent installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version Windows after SCCM agent installed: c:\windows\system32\ccm\logs\Smstslog\smsts.log
  • Full version Windows (x64) after SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
  • After Task Sequence has finished running: c:\windows\system32\ccm\logs\smsts.log
  • After Task Sequence has finished running (x64): c:\windows\sysWOW64\ccm\logs\smsts.log

Ports Required to Join a Windows Domain – Managing Windows Machines in a DMZ with SCCM

For those looking for the ports you need open, this is what I use for a Windows 7 and Windows 2008 R2 DC.

LDAP TCP-in – 389
LDAP UDP in – 389
LDAP for Global Catalog TCP in – 3268
NetBIOS name Resolution UDP in – 138
SAM/LSA TCP in – 445
SAM/LSA UDP in – 445
Secure LDAP TCP in –  636
Secure LDAP for Global Catalog TCP in – 3269
W32Time NTP UDP in – 123
RPC – RPC Dynamic
RPC Endpoint Mapper
DNS – TCP and UDP 53
Kerberos V5 UDP in – 88
Netbios Datagram UDP in – 137

Now for the long story (note that the below solution is conceptual and hasn’t been tested in a lab yet. This is just me getting things written down. I’ll update more after we put this in place) –

When managing machines that are behind a firewall, you’ll need to open ports on the firewall to get them joined to a domain. I have an interesting situation coming up next week where we need to manage machines that are in my customer’s DMZ. In the current customer’s environment, the machines in their DMZ are workgroup machines that aren’t joined to a domain.

From an SCCM Perspective, we can manage workgroup machines. However we still need the ports opened through the firewall to manage these machines. In some cases, network administrators don’t want all of their DMZ machines to go through the firewall that separates the DMZ from the internal network. We haven’t determined if that’s a route we want to take, but I personally feel that the more machines you have that can route through the firewall, the more you increase your attack vector.

My proposed solution would be to build up a secondary SCCM server in the DMZ that can only communicate through the firewall. All of the other machines in the DMZ would communicate through that server. That server doesn’t even HAVE to be a secondary site, we could just build one box with an MP and DP (or whatever other site roles you need). The secondary will just allow us to throttle bandwidth if needed.

Below is a diagram that we use for Internet Based Client management, but for managing machines in the DMZ, the process would be the same.

Network Diagram for Internet-Based Servers - Scenario 3 with No SQL Server Replica

So in our case, since there will be less than one hundred machines in the DMZ that need to be managed, we’ll probably put all site roles on one box. We’ll then need to open the ports I referenced above to allow the server to join the domain (note that all site system roles MUST be apart of a domain. They don’t have to be apart of the same domain as the site server, but they do need to be part of a domain.). Once the server is joined to the domain, we’ll need to open either port 80 or port 443 (for HTTPS) outbound to allow for the Software Update Point to communicate through the firewall. The diagram says HTTPS, but we can use HTTP since we’ll be in a mixed mode environment. For native mode environments you’d need to utilize HTTPS. We’ll also need SMB 445 outbound open to allow the site server to communicate with the other site roles in the perimeter network. We’ll also need to create an inbound rule for SQL on port 1433 for the management point to communicate with the SQL DB.

Once we’ve done all that, we’ll need to setup the appropriate rights to allow for site system installation on our server.

Client Configuration (thanks to Chris Stauffer for these tips)

In our scenario, we will be able to map to the MP’s client share to install ccmsetup.exe. We can use the ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ. We’ll likely also need to make some adjustments to the LMHosts and Hosts file.

Note that these tips should work if you have the firewall rules enabled for your clients to communicate through the firewall which would be port 80 or any custom port you’ve allowed SCCM to use.


Add the SMS information to a LMHOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name): ws03dc01                        #PRE “SMS_SLP            \0x1A” #PRE “SMS_MP              \0x1A” #PRE “SMS_NLB             \0x1A” #PRE
# “12345678901234567890”
(note that there are 20 characters between the quote marks on each line, and the last line is just to help with spacing – it is not needed)

HOSTS file:

Add the SMS information to a HOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name): ws03dc01.domain.lcl ws03dc01


Build a server in the DMZ
Open the following inbound ports on the firewall to allow the server in DMZ to join the domain

LDAP TCP-in – 389
LDAP UDP in – 389
LDAP for Global Catalog TCP in – 3268
NetBIOS name Resolution UDP in – 138
SAM/LSA TCP in – 445
SAM/LSA UDP in – 445
Secure LDAP TCP in –  636
Secure LDAP for Global Catalog TCP in – 3269
W32Time NTP UDP in – 123
RPC – RPC Dynamic
RPC Endpoint Mapper
DNS – TCP and UDP 53
Kerberos V5 UDP in – 88
Netbios Datagram UDP in – 137

Open the following outbound ports on the firewall to allow SMB and HTTP traffic


Open the following inbound port on the firewall to allow SQL Traffic from the MP

SQL TCP – 1433

Give rights for the site server on the intranet to the site system server in the DMZ so the site systems can install on the server.

Setup Site Roles (DP, MP, SUP)

Setup a test client and make changes to LMHOSTS and HOSTS file (if needed, not sure if necessary yet).

Install SCCM client with ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ

Some may say to use an FSP. I don’t know that it’s necessary. These client installs will be done manually, and i’d rather look at the client logs.

We’ll see how well this works this week. I’ll post an update by end of week.

System Center Configuration Manager R3 Released!

Today Microsoft released SCCM 2007 R3! Instead of going into a long blog post about all the exciting new features R3 has, I’d like to refer to an EXCELLENT run down of all the features by a co-worker of mine, Steve Rachui. If you run SCCM, R3 is definitely a worthwhile update that’s painless to implement into your existing environment.

Check out Steve’s post here.

Download the evaluation copy here.

Read the official announcement here.

SCCM: Collection Query to Find Machines Discovered via AD System Discovery in the last day without latest SCCM Client

In the final days I have with my current employer, I’ve been doing some client cleanup. As you may know, Active Directory System Discovery can make a mess out of your SCCM environment if AD isn’t kept clean. We have a lot of records in our DB that just don’t have the SCCM Client for a variety of reasons (not enough disk space, WMI is broken, etc).

The good thing about AD System Discovery though is that for each record it finds in AD, it’ll look to DNS to see if there’s a corresponding DNS record. If there is, it’ll create a DDR for that machine. So if you have a lot of junk in AD, and DNS scavenging is set to a reasonable amount of time, you should be seeing machines in your SCCM hierarchy that are actually on your corporate network.

So what I set out to do was look for all the machines that have reported back an AD System Discovery record within the last day (technically, the query below is referencing 23 hours) that doesn’t have the latest version of the SCCM client (or the client version is null). Here’s the query.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where ((DATEDIFF(hh, SMS_R_SYSTEM.AgentTime, getdate()) < 23) and AgentName = “SMS_AD_SYSTEM_DISCOVERY_AGENT”) and (SMS_R_System.ClientVersion < “4.00.6487.2000” or SMS_R_System.ClientVersion is null)

This gives me all the machines that I need to look into to fix. These are machines I wasn’t able to hit using Client Push installations, or at least I never got a successful client installation for them.

SCCM SCUP: How to Install Adobe Flash Player

With the new release of Flash Player 10.1 I’ve noticed in our environment that we were unable to install the Active X component for IE systems using the provided MSI file with SCUP. I’ve read in a few places that it’s best to utilize the .exe instead of the .msi that is provided by Adobe. So this evening I decided to do so.

Adobe has changed its command lines for flash 10.1 this go round. Originally I was using /s for a silent install but I noticed in Taskmgr that the .exe was sitting under the SYSTEM context doing nothing.

Appdeploy has an entry for Adobe Flash 10.1 that recommends to use -install for a silent install with the .exe form of installation. Once I added the -install switch, things worked just fine.

Now to figure out whether the mms.cfg file works still.

MS10-041 KB979909 .NET Framework 3.5 Service Pack 1 and for the .NET Framework 2.0 Service Pack 2 for Windows 2000, for Windows Server 2003, and for Windows XP Fails to Install

Sorry for the long title.

This past Tuesday Microsoft released a slew of new security patches. I won’t go into detail about all of them, but suffice it to say we’re seeing KB979909 become a pretty hairy thorn in our side.

We deploy all of our updates via SCCM. In my pilot testing I’ve noticed quite a few machines that come up with an error code of -2147023293 with a HexErrorCode of 80070643. This error basically means a fatal error during installation.

Microsoft’s recommendation on how to fix this is referenced here: however what I’m seeing in my environment is nearly a 10% failure rate on my pilot users. There’s no real easy way to fix this remotely, and my help desk will be busy for a couple of days fixing this issue for the amount of calls they’ll be receiving.

Other people are seeing the same problems. For the time being, we’re pulling the update until we see a better solution than uninstall all versions of .NET as the fix.

Below are links to other people experiencing the same problem with this update. Some are also seeing problems with KB982168, and KB979906.

If you’re having the same problem, post a comment below.