Deployment | Todd's Blog

Managing Drivers in Task Sequences with System Center Configuration Manager 2012

posted on February 19, 2014

When of the question I always get when deploying Windows whether it be Microsoft Deployment Toolkit or System Center Configuration Manager is how to I properly deploy drivers.

Now there is no right or wrong way, but I always steer people away from putting them in one big folder and letting the OS figure out which to use. Have you ever seen a Dell using an HP Driver? Been there so here is a flashback of a back post of how to manage drivers in MDT.

Let’s take a quick look at how to clean this up in System Center Configuration Manager. Basically add your drivers and put them into folders and then add them in as driver packages.

Then when setting up your task sequences, add a section where it evaluates the machine type and if it matches, apply the drivers.

Here is a screen shot of a task sequence in System Center Configuration Manager I did for a customer.

What happens here is as the task sequence continues along, it checks to see if the drivers need to be applied based on a WMI query. To get this information use WMIC to pull out the model information.

Further along we install applications that are drivers, but poor ones in that they need to be installed. Again we use a WMI query to only install the application if it matches the make and model of the device we specify.

Planning a Windows 7 Deployment

posted on March 31, 2012

Last July I left the County of Lennox & Addington and moved to the Upper Canada District School Board. One of the the first things I helped with was the Windows 7 Deployment.

This Windows 7 deployment is a 11,000 seat deployment and when I joined, the image was just about finalized. At this point the heavy lifting of planning, and figuring out what is in the environment was completed, but let me help you walk through your planning.

The first thing you need to do is get a sense of what your hardware is. In our environment,we have a tool that was developed to track that information. But you don’t need to reinvent the wheel, Microsoft makes a great tool FREE tool called MAP, Microsoft Assessment and Planning (MAP) Toolkit. You run this tool against your AD computer and then you get a great report of what is in your environment and what the capability of the computers are.

After running this tool, you should also be using the Application Compatibility Toolkit, another free tool. This application runs creates an MSI that is run on workstations. I push it out with GPO but you can use any tool you have to push MSIs out. This tool then runs for a predetermined amount of time (you set that) and then it returns what applications are installed and how much it has been used. From that report, it will make a list of what you have running for applications and which ones are supported on Windows 7. It also contains fixes for common application which won’t work natively with Windows 7. We used this tool to fix AutoCad 7 when it wouldn’t work correctly with Windows 7.

So, those two tools will help you get planning your Windows 7 deployment. Use these two tools, gather your information and plan your deployment. Good planning upfront will prevent a lot of a pain in the deployment phase.

In another post, I will cover off the deployment side.

Slow Logins

posted on February 13, 2012

Just before Christmas holidays, we started receiving calls about sporadic slow logins in our schools. Now slow logins can be a real pain to troubleshoot and somewhat difficult to replicate the issues. We also noticed it was only student logins with the issue. Staff and admin logins were not affected.

We headed to one of the elementary schools and started investigating. I used wire shark to sniff the port of the computer we were testing with and I used the Sysinternal tools. We were able to replicate a slow login and started using gpupdate /force. If it updated with one specific DC, it would take somewhere in the neighbourhood of 10 minutes to update. It would take 45 seconds against the rest of the domain controllers. I also noticed the workstation was receiving the policy file 2 bytes at a time.

This was odd, so we decided to vMotion the virtual machine which is the DC to a different host. This fixed the issue and the updates were about 45 seconds now. So wanting to know if the problem was a host problem, we moved the virtual machine back to the original host and it still worked keeping our logins at 45 seconds. Not entirely sure what was happening but happy to have fixed the problem, we headed back to the office.

We checked in with Tier 1 support and let them know we solved it, not certain it would be a long term fix and wanted to made aware of any further calls.

The next day the calls were back. So I used the IT techs favourite troubleshooting tool.

Google.

I found this KB article. http://support.microsoft.com/kb/319440. The machines that were affected were for sure Windows XP machines. I can’t remember now if we saw this behaviour on our Windows 7 computers. But at that point, we had just began our 11,000 seat Windows 7 deployment.

I added the entry I typed up here to the Group Policy preference to the GPO that was applied against the computers being affected.

Registry subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Entry: BufferPolicyReads
Type: DWORD
Value: 1

Once this change was made, we update Group Policy and then headed to a school. It also had the benefit that good gpupdates went from 45 seconds to 15 seconds.