SCCM

Controlling Configuration Manager Clients Across WAN Links

Richard Green on

At work this week, we encountered an issue when a package I created for Adobe Reader 10 went mandatory in Configuration Manager. We service retail stores connected via slow WAN links back to our head offices. When I first joined the company, on a monthly basis when new Windows Updates were released into the wild, our network team would come down upon our team, fire wielding whilst we raped and pilaged the lines to stores.

Configuration Manager gives you the power to create BITS (Background Intelligent Transfer Service) policies to throttle the bandwidth that will be consumed by SCCM client transfers for packages and patches, however the problem with Configuration Manager is that it’s policy is not granular, it is singular which means to apply a policy of 32KB/s which we needed to do to facilitate stores, you would also be limiting the speed of head office clients connected to 100 Megabit or 1 Gigabit high speed LAN connections.

Group Policy also gives you the ability to configure BITS throttling policies and in actual fact, Group Policy gives you more options to control the granularity plus the fact that you can link Group Policies to OUs and not just entire domains, or sites, allows us to control the speeds in a more appropriate way.

In a Group Policy Editor window from Group Policy Management Console (GPMC), navigate to Computer Configuration, Administrative Templates, Network, Background Intelligent Transfer Services (BITS). From here, enable the Limit the Maximum Network Bandwidth for BITS Background Transfers setting and configure the speeds and times as you need. You can also configure an out of hours policy which we make use of, limiting the store clients to 32KB/s between 8am and 6pm daily, but allowing them to expand to 256KB/s overnight when the store is closed, not making VoIP calls or trying to transact credit cards.

This worked great and the next time we deployed patches we had no complaints from the stores, but instead, we had a problem at the head office. The problem had not been manifested previously as we had to delay patch deployments before the packages reached everyone, but the issue we experienced now was that due to the length of time a Configuration Manager client was connected to the Distribution Point downloading packages, we were now seeing prolonged connections to the IIS site on the Distribution Point and lots of 64KB/s connections makes lots of bandwidth – We were now actually consuming all of the bandwidth at the head office site, causing inter-site applications between our two head offices to crawl.

We found a solution to this problem in IIS. The solution probably isn’t recommended by Microsoft or any System Center consultants out in the wild, but it works for us and causes no side-effects that we’ve witnessed in the year or so that it has been in place, so it has withstood the test of time.

Using IIS Manager on the Distribution Point server, expand the Default Web Site. From the Actions pane on the right hand side of the interface, select Advanced Settings. From the Advanced Settings dialog, expand the Connection Limits group under the heading Behaviour. By default, IIS accepts a number of connections so large is may as well be infinite. We calculated that based on our free capacity on our link at the head office, taking into account the traffic required for LoB applications, we could handle about 20Mbps of client traffic. We divided the 20Mbps into 64KB/s BITS setting out which gave us a number of 320. Setting the IIS connection limit to 320 and restarting the site in IIS, we saw an instant reduction in Distribution Point server network activity and also the drop we needed on the site link.

As I have mentioned above, this was done over a year ago. In this time, we’ve had not a single complaint from stores, head office users or our network team that there are network contention issues due to SCCM traffic, nor have we seen any apparent SCCM client issues such as clients never properly reporting due to connection retry limits being reached. This isn’t to say that this fix is for everyone: You would need to factor in things like how many total clients do you have in an SCCM site, and if a client was back of the IIS queue, would it be waiting for a connection for so long that it would timeout, or do you need to be able to rapidly deploy high threat updates regardless of the impact to other LoB applications?

Since implanting these changes, we’ve had two Microsoft SCCM RAP assessments and neither have produced red or amber health status problems due to the changes to BITS and IIS, so I think we found ourselves a winner.

Failure with Concessions

Richard Green on

Today wasn’t the greatest day for me in one respect. Unfortunatly I flunked my 70-236 Configuring Exchange Server 2007 exam for the second time, and strangely, with months more Exchange experience under my belt (and I mean that because we’ve faced our share of issues and undertaken our share of mini-projects on infrastructure engineering since my last attempt), and with loads of preperation, I actually scored roughly 75 points lower than my first attempt.

I purchased a three exam pack through Prometric earlier in the year which expires December 31st 2011, so I’ve got to try and get two exams passed before the end of the year still, with MDOP being my next exam and still undecided on the third, but Exchange better look out, as once I’ve done my two remaining in the pack, I’ll be going back for my MCITP for Exchange Server 2007 and 2010.

The concession in all of this is a feeling of self-enlightenment. Tomorrow, my trusty laptop will be going back to the office from home so that I can re-deploy it with SCCM to install my yummy new SSD disk (I would clone the disk, but I have a feeling BitLocker might not accept that too kindly). To make sure I didn’t loose any data, I hooked up my VPN this evening and made sure that all of the data on my laptop was safe and sound on the file servers and work, and then I turned my attention to OneNote.

I’m an avid OneNote user, and will use it over written notes whenever I possibly can. Being a Windows Phone 7 user, I also enjoy the OneNote integration in the phone giving me super access to my personal notes. I quickly realised that through the course of migrating through various working practices at work, I had one notebook in my SharePoint 2010 MySite and another locally on the laptop, and then a third in the Windows Live SkyDrive cloud. I’ve just combined them all into my SharePoint 2010 MySite notebook and I feel great for it.

Unification for the win 🙂

App-V Client Management via GPO

Richard Green on

Deploying the App-V Client to end-user machines can be headache. Microsoft provide ADM files for managing the configuration of the App-V Client via Group Policy in AD DS, however if you are trying to deploy the client yourself, you will soon discover that the Microsoft ADM files don’t allow you to configure an App-V Publishing Server. The only options you have with the ADM files are to override the sequenced application package and icon source roots.

Using this method, you install string for silent installation will look something like this:

setup.exe /s /v” /qn SWIPUBSVRDISPLAY=”App-V Server” SWIPUBSVRTYPE=”RTSP /secure” SWIPUBSVRHOST=”SERVERNAME” SWIPUBSVRPORT=”322” SWIPUBSVRREFRESH=”on” SWIFSDRIVE=”Q””

As anyone can see this isn’t exactly elegant, and if you are using SCCM to deploy the App-V Client as I am, you will soon discover SCCM has a character limit for the installer path which means you may have to turn to building a batch file to execute the installation and then call the file in the SCCM Program.

The other problem you will have are that you are then hardcoded to use the server name and port specified in the install. Yes, you could use a DNS CNAME to direct your clients to the App-V servers, and sure you can use a GPO to edit the registry keys on the end-user machines after the fact, however none of this is elegant as properly managing the deployment.

Introducing Login Consultants, a Netherlands based virtualization specialist company. This company provide a third-party ADM file for you to import into AD DS for extending the management options for App-V from the Microsoft ADM file, and best of all, you can register and download the ADM file for free from http://www.loginconsultants.com/index.php?option=com_docman&task=cat_view&gid=20&Itemid=149.

Using the Microsoft ADM file and the Login Consultants ADM file in conjunction, your install string turns into this:

setup.exe /s /v” /qn”

Much cleaner, easier to setup in Configuration Manager and then it gives you the ability to manage all of your App-V server configuration, including server name, ports, protocol, SFT_SOFTGRIDSERVER environment variable and all the other settings you need via Group Policy.

For centralising and streamlining management, this is a huge boon, as it means you have a one size fits all deployment of the App-V Client and then allowing you to manage everything else from either AD DS or from the App-V Management Server.

Package Fails to Distribute in SCCM When an autorun.inf File is Present

Richard Green on

At work this week, I was working with an Intel HD Graphics driver package which in terms of SCCM, you would call a bad driver. We call it a bad driver because it is a driver which doesn’t not install correctly using the Apply Device Drivers OSD step but instead requires a full application to be executed.

After creating the package in SCCM, I proceeded to distribute the package to our distribution points on the network so that the operating system deployment process would be able to access the files required to deploy the application.

After waiting a short while for the package to distribute, I checked the Package Status view in the ConfigMgr Console, and I saw that the status was Install Retrying. After looking at the status log for the distribution point, I saw that it had already gone into a retrying state several times. If received the following error:

SMS Distribution Manager failed to copy package "SITE0011C" from "\SERVERPATHIntelHD Graphics Display Driverx64" to "MSWNET:["SMS_SITE=SITE"]\SERVERSMSPKGD$SITE0011C".

Possible cause: SMS Distribution Manager does not have sufficient rights to read from the package source directory or to write to the destination directory on the distribution point.

Solution: In the SMS Administrator console, verify that the site system connection accounts have sufficient privileges to the source and destination directories.

Possible cause: The distribution point might not be accessible to SMS Distribution Manager running on the site server.

Solution: If users are currently accessing the package files on the distribution point, disconnect the users first. If the package distribution point is located on a Windows NT computer, you can force users to disconnect by clicking on the "Disconnect users from distribution points" box in the Data Access tab of the Package Properties dialog box.

Possible cause: The distribution point does not have enough free disk space to store the package.

Solution: Verify that there is enough free disk space.

Possible cause: The package source directory contains files with long file names and the total length of the path exceeds the maximum length supported by the operating system.

Solution: Reduce the number of folders defined for the package, shorten the filename, or consider bundling the files using a compression utility.

I logged into the effected distribution point and verified that the file shares used by SCCM where still active and that there was sufficient disk space on the server which there was.

I have encountered issues with package distribution before with a Windows 7 64-bit image was refusing to distribute, but I couldn’t find any cause, and in that instance re-creating the package resolved the issue, so my first port of call was this. On the sources directory, I made a new folder and copied the source files from my workstation fresh to the server in case there had been a problem with the previous file transfer.

On this occasion, whilst copying the files, I got an error whilst trying to copy the files, and it specifically generated the error no the autorun.inf file which was included in the download from the Intel site. I thought this was wierd, but knowing how invasive our McAfee enterprise policies can be at times, I wondered if the autorun.inf file was causing an issue. I deleted the autorun.inf file from the original package sources directory on the server and watched while SCCM happily distributed the package to the distribution points.

After a quick bit of investigation, I soon discovered a setting in McAfee VirusScan called Prevent Remote Creation of autorun.inf Files which was enabled. Because SCCM uses SMB to transfer the packages from the source directory to the distribution points, this triggered the McAfee rule and blocked the entire package from being created.

As a rule on thumb, there is no reason to have autorun.inf files inside your SCCM packages and their source directories, so in this instance I simply omitted the file, however if you needed to keep the file, then you could simply disable this protection rule for your SCCM Site and Distribution Point servers and the server which holds your package source files (perhaps a File Server). Although I have mentioed McAfee as the culprit in this scenario, I’m pretty sure that other anti-virus applications will feature a similar rule which could cause you other headaches.

So Long, So Busy

Richard Green on

It’s been quite a while since I’ve posted anything and for that I am disappointed, however I do have just cause.
Since my last post, me and the wife Nicky have been working the Cambridge Weight Plan and in one week I lost 10lb which is amazing. We’ve got Nicky’s Dad over this week helping us with some lose ends of DIY in the house too, so my evenings are packed with DIY work.

Back in the land of tech, I’ve been busy on a MIMEsweeper for SMTP training course, a Websense training course, and working feverishly hard on System Center Configuration Manager and Exchange. I’m hoping I’ll be coming out with a couple of posts soon on these subjects, along with some bits on Windows Home Server 2011.