ConfigMgr 101: Control your Distribution Points

On almost every consultation visit to healthcheck a ConfigMgr impementation it seems some solution providers are forgetting about the basics, such as when provisioning a new Distribution Point there thought should be given to controlling exactly which drives ConfigMgr content can occupy.

Firstly, we need to consider compressed package content (.PCK files) that arrive at the site, which by default get stored in an “SMSPKG” folder on the root of the same drive as the site installation files.  To control the drive used for compressed content, simply set your desired drive letter in the “Software Distribution” component within the “Component Configuration” node of your site.  Give that time to apply and then when you send content to that site it will be stored where you want it to be.

Secondly, we need to control where compressed content can be decompressed to. If you have ever taken the time to watch the distmgr.log on a site you will see entries which show ConfigMgr figuring out which drive is best to decompress to, mainly based on available freespace.  Freespace changes, thus content may sprawl across any and all drives it sees.  Decompressed content resides in “SMSPKGX$” folders (where X represents the host drive letter) on the root of utilised drives.  We need to reign in this behaviour, and this is accomplished by creating a small file called “no_sms_on_drive.sms” on the root of whichever drives you DO NOT want ConfigMgr to consider as a possible destination for decompressed content.

Get this set right from the outset and you will save a lot of trouble later on trying to relocate and re-pushing content to DP’s to fix everything to where it needs to be.


Forefront Endpoint Protection 2010 Software Update 1 – SoftwareUpdateAutomation.exe

This is just a quick post to suggest a great way of using the SoftwareUpdateAutomation.exe utility used with FEP 2010 SU1.  You first need to copy the SoftwareUpdateAutomation.exe to the “<ConfigMgrInstallDir>\AdminUI\bin” folder on your Central Site server.

I have seen various blog posts that suggest creating a scheduled task to run on an interval appropriate to how often you expect FEP updates to be released by Microsoft, but I feel the best thing would be to schedule this utility (which updates your FEP Definitions Deployment and Software Update package) to run after a Synchronisation by your Software Update Point component.  Part of my reasoning for this is that the SoftwareUpdateAutomation.exe will trigger an update of your FEP 2010 Definitions Package regardless of the fact that there might be no changes to replicate.

To do this, simply create a scheduled task on your central server to run under an account with the proper permissions, use the command line;

SoftwareUpdateAutomation.exe /AssignmentName <YourAssignmentName> /PackageName <YourDeploymentPkgName> /RefreshDP /UpdateFilter "ArticleID='2461484' AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0"

For the New Trigger properties, choose to begin the task ‘On an event’ and use the following parameters;

This will cause the task to fire shortly after a successful WSUS Synchronisation event (Log: Application; Source: SMS Server; Event ID: 6702.)  The 30 minute delay should allow sufficient time for your Software Update Point to complete the post-synchronisation shuffle of Status Messages around your infrastructure.

I think this is a more elegant solution than having it run regardless of your WSUS schedule and you can now control the frequency of this tool simply by altering your SUP Synchronisation Schedule – which you should be mindful of NOT doing too often if your infrastructure simply isn’t capable of making the changes on all Site Servers and Distribution Points before the next scheduled run.


Well I didn’t know that! State Migration Point USMT.MIG files and Windows Easy Transfer.

I get a nice warm feeling inside when I accidentally click on something but get rewarded with a new little piece of knowledge.  This recently happened when I was browing the ConfigMgr State Migration Point store from a Windows 7 system, double clicked on a USMT.MIG file, and was introduced to Windows Easy Transfer.  I’ll admit to having heard of Easy Transfer but considering myself as more of an enterprise solution implementer nowadays I didn’t give it much consideration and dismissed it as a ‘Home User’ type of thing.  I was wrong.

I am often asked the question of how best to restore previously captured User State data from a ConfigMgr State Migration Point should ‘something’ go wrong – for instance if the State Restore during OSD should fail.  My previous answer used to suggest the use of the command line and the USMT LoadState.exe – but now my answer now is simply “Use Easy Transfer.”

You can browse to your SMP using a Windows 7 system and double click on the USMT.MIG file created by the State Capture phase of your task sequence to start using Easy Transfer…

You are required to enter a recovery password…

The recovery password can be found by viewing the ‘Recovery Information’ of the Computer Association object that was created within the ConfigMgr console and it is the ‘User State Recovery Key’ you are interested in…

Use this key as the password for the Easy Transfer Wizard and continue…

Well this interface is a darn sight easier to use than the USMT command line!  The ‘Advanced Options’ give you some control over mapping migrated data to other user accounts.  Hit the ‘Transfer’ button…

Once the transfer is complete, you will be presented with a summary screen from which you can choose to view extended details and reporting data on what exactly was transferred…

Marvellously simple – and much, much better than having to either manually initiate USMT LoadState.exe or advertise and run a Task Sequence just to perform a restore.


Forefront Endpoint Protection (FEP) 2010 and ConfigMgr OSD Task Sequence

Microsoft’s preferred delivery and management mechanism for the Forefront Endpoint Protection (FEP) 2010 client is apparently ConfigMgr.  Deploying the FEP 2010 client to a running ConfigMgr client is relatively painless, but getting the FEP 2010 client installed and up to date as part of an OSD task sequence can be a royal pain.

There are a few potential pitfalls you will need to be aware of and I’ve attempted to list them in the order you’ll likely find them.

Run from Distribution Point

If you want to run your Task Sequence with the “Run from Distribution Point” option, you can forget about using the default ‘Install’ program in the ‘Microsoft Corporation FEP – Deployment 1.0″ package that gets created out of the box – it’s no good for us in this scenario and there are a couple of reasons why not; not least that various well respected Microsoft MVP’s state categorically that it has to be downloaded locally first.

But why?  Well, I’m assuming you unticked the ‘Allow users to interact with this program’ option on the ‘Install’ program environment options and then created a new ‘Install Software’ step in your task sequence and found the step is failing in your task sequence…

  • Error 2147942401.  Result = No FEP 2010 Client installed.  This is because the ‘Install’ program makes use of a script called ApplyPolicy.vbs – which if you poke around inside it you will see that it attempts to create a WMI class by writing and compiling (using mofcomp) a file called ‘CCM_ISV.mof’.  The creation of this file will fail because the SYSTEM account cannot write into the current working directory – which will be your DP.  Contrary to some suggestions out there, changing the ‘Install’ program environment properties to ‘Requires drive letter’ will not help you here, it’s totally a permissions thing and the error will be the same.

There are a a few blog posts kicking around that suggest creating a new install program using just the command line ‘FEPInstall.exe /s /q’.  This will work with ‘Run from Distribution Point’, however you end up with a deployed client without a default policy and it is not locked down, therefore I wouldn’t go down this route.  You CAN specify a default policy to apply using the /policy switch on the command line, however this would require the full path specified to the policy file otherwise you will get;

  • Error 2147156116.  Result = No FEP 2010 Client installed.  This is because the policy file specified was not found.

You need to hardcode a path or create an install.cmd in the root of the package source to run on your program command line which makes use of the %~dp0 variable internally. e.g:

"%~dp0FEPInstall.exe" /s /q /policy "%~dp0Policies/Default Desktop Policy.xml"

Whilst the above solution certainly works, it is not the best solution as you are straying away from how Microsoft intended you to install the FEP 2010 client using the ApplyPolicy.vbs script.   This script does some clever stuff like handling the creation of a WMI class that is needed to house a FEP policy and can pull down any existing policy which may apply to the system being built/refreshed – but I don’t profess to understand it 100%.

My preferred method of installation is to use an install.cmd which first copies down the FEP 2010 client install folder locally to %TEMP% and then runs the correct command line for the install from there;

xcopy "%~dp0*.*" /e/s/y "%TEMP%\FEPInstall\"
cd %TEMP%\FEPInstall
cscript.exe Policies\ApplyPolicy.vbs "FEPInstall.exe /s /q "

This is pretty much running the installation as Microsoft intended – but giving us the bonus of being able to use the ‘Run from Distribution Point’ setting on our task sequence advertisement, if we wanted to, without the ApplyPolicy.vbs script encountering permissions issues.  You could of course tidy up afterwards by deleting the %TEMP%\FEPInstall folder.

NOTE: I really wish Microsoft would incorporate a ‘Download and Run’ option on a per-task sequence step basis.

Congratulations!  You should now be seeing a successful Forefront Endpoint Protection 2010 client install in your task sequence, but there may be more to do…

Initial Updating of the FEP 2010 Client

It is not an unreasonable thing to expect the newly installed FEP 2010 client agent to be up to date as soon as it is deployed, and the client attempts to take care of this itself moment after installation during OSD but it will likely fail and leave the user vulnerable until the issue is resolved either manually or (eventually) by ConfigMgr performing a Software Updates cycle.

I’m assuming you have gone through the usual steps of enabling an auto-approval rule for FEP 2010 definition updates on your WSUS server and that you may also have downloaded and implemented the ‘SoftwareUpdateAutomation.exe’ from the latest Update rollup for FEP?  If not, you should – but I won’t go into that right now.  You basically want your WSUS server and ConfigMgr servers sorting themselves out with the latest FEP 2010 definition updates at least once a day.

So you have all of that in place, but still you are left with a FEP client that isn’t up to date shortly after build, why?  The most likely explanation is;

  • Corporate Proxy Rules.  Your corporate Internet proxy may not be allowing outbound traffic from non-authenticated users.  You will see this in the ‘%windir%\windowsupdate.log’ on the client shortly after installing FEP 2010 as repeated http send request failures.
  • FEP 2010 Definition Updates not targeted at build collection.  It has always been a hack job getting Software Updates applied to a new system being built – the concept of having to target your Live Updates at collections of existing systems AND ALSO to the collection to which the Task Sequence is pointed at is most annoying.  This doesn’t help much anyway during OSD, as you’ll discover.

If the machine that FEP 2010 is installing onto is able to get straight out onto the Internet then it will likely update itself directly from Microsoft, which you will see in the ‘%windir%\windowsupdate.log’ as showing data coming from ‘…’ in which case all is well.  You must consider however that the FEP updates can run to around 130MB, and if you also don’t fancy opening up your Internet proxy to anonymous usage (and you shouldn’t!) then ideally we need our own internal WSUS server/ConfigMgr Software Update Point (SUP) to service the initial FEP request for Definition Updates – but this is frustrating during OSD…

  • NO WSUS Server set.  Here’s the pig!  During an OSD task sequence the ConfigMgr client is in a ‘provisioning mode’ – that is to say, the client agents are not fully enabled.  This means that the local Automatic Updates policy has not been fully configured with a local SUP server name and this will cause the FEP 2010 client to resort to trying to go outbound.  An ‘Apply Software Updates’ step ran before the FEP 2010 install step temporarily encodes the SUP server name and deploys any Software Updates targeted at the build collection – but from what I have seen this setting doesn’t stick around for the FEP 2010 post-install update to use.  If your next thought was to maybe run the FEP 2010 installation and then an ‘Apply Software Updates’ step this still seems to result in the FEP 2010 client generating http send request failures in the Windows Update Agent (windowsupdate.log).  The FEP 2010 client did seem to get updated using this method on occasion, but it was very hit and miss.

After a lot of experimenting to generate a consistently successful installation and update, the resolution for me was to change at what point I install the FEP 2010 client during OSD and relying on timing!  I kept the installation of the FEP 2010 client away from the main bulk of Software Applications and instead I have the very last two steps of my OSD task sequence to run my custom FEP 2010 client install command and then a ‘Restart Computer’ step without a delay back into the Installed Operating System.  This seems to have the desired effect of getting the FEP 2010 client to use the WSUS server as configured by the now active ConfigMgr client.

I have noticed that for this trick to work though, you DO need to have an ‘Install Software Updates’ step in your task sequence.

Good luck!


* Disclaimer: This blog represents the personal views and experiences of the author only and is provided as-is without any warranty or implication of fitness for purpose.  What works for me, may not work for you.