System Center 2012 Service Pack 1 CTP2 announcement

A few weeks ago during TechEd 2012 NA the System Center 2012 Service Pack 1 CTP2 was announced. The Service Pack contains updates to System Center 2012 for compatibility with Windows Server 2012 Release Candidate including support for Azure VM and capabilities for Hosted Service Providers.

It is available for download here: System Center 2012 Service Pack 1 CTP2

This Community Technology Preview (CTP2) enables System Center customers to jointly evaluate System Center 2012 and Windows Server 2012 Release Candidate. CTP2 includes updates and enhancements to the following System Center 2012 components:

• Virtual Machine Manager
  • Improved Support for Network Virtualization
  • Extend the VMM console with Add-ins
  • Support for Windows Standards-Based Storage Management Service, thin provisioning of logical units and discovery of SAS storage
  • Ability to convert VHD to VHDX, use VHDX as base Operating System image
• Configuration Manager
  • Support for Windows 8
  • Ability to deploy Windows 8 Apps
  • Real-time administrative actions for Endpoint Protection related tasks
• Data Protection Manager
  • Improved backup performance of Hyper-V over CSV 2.0
  • Protection for Hyper-V over remote SMB share
  • Protection for Windows Server 2012 de-duplicated volumes
  • Uninterrupted protection for VM live migration
• App Controller
  • Service Provider Foundation API to create and operate Virtual Machines
  • Support for Azure VM; migrate VHDs from VMM to Windows Azure, manage from on-premise System Center
• Operations Manager
  • Support for IIS 8
  • Monitoring of WCF, MVC and .NET NT services
  • Azure SDK support
• Orchestrator
  • Support for Integration Packs, including 3rd party
  • Manage VMM self-service User Roles
  • Manage multiple VMM ‘stamps’ (scale units), aggregate results from multiple stamps
  • Integration with App Controller to consume Hosted clouds
• Service Manager
  • Apply price sheets to VMM clouds
  • Create chargeback reports
  • Pivot by cost center, VMM clouds, Pricesheets
• Server App-V
  • Support for applications that create scheduled tasks during packaging
  • Create virtual application packages from applications installed remotely on native server

For ConfigMgr 2012 it includes also additional operating support to extend manageability to Mac OS X and Unix/Linux servers. Nice to see that ConfigMgr 2012 has cross platform support soon!

How to manage Obsolete clients in ConfigMgr

When deploying devices multiple times a day, for example when testing a new Task Sequence, ConfigMgr clients will become obsolete. This because everytime a device gets a new image, the ConfigMgr client will be installed again with a new GUID. The older object will be marked as obsolete, and a new object becomes available. Because of this obsolete object, OS deployment and Software distribution doesn't work anymore. This can be managed as follows.

First configure a Maintenance task for deleting them automatically. Go to Site Management > Site Settings > Site Maintenance > Tasks for enabling and configuring "Delete Obsolete Client Discovery Data". This way daily management of obsolete clients is not needed anymore. Mostly the following configuration I choose at customers:

This because this task is disabled by default, and deletes only data older the 7 (seven) days. Because I want a daily refresh in colllections, I choose to set it to 1 (one) day. This is the only thing in ConfigMgr for automatically deleting obsolete clients. But what to do when there will be multiple deployments on the same day, with the same device? Then manually delete the obsolete client is needed. For doing that, the following must be done:

Go to the All Systems collections and choose "Update collection membership". Also do a refresh afterwards. Then multiple objects can be available for the same device. Delete the Obsolete one will also then delete this object from other collections. That's pity! So remember to which collection(s) this device belongs! There is also another way for recognizing multiple objects.

Go to the collection where your device is placed for OSD (for example). Now rightclick on this collection and choose properties > Membership Rules. Click the blue computer icon for adding new devices:

Choose System Resource (Resource class) & Name (Attribute name). Fill in the device name searching for (Value):

Don't use Collection Limiting for searching devices, otherwise you have less change to find them:

When having obsolete client data, multiple devices will be seen. Choose "Select All" for adding them to the collection:

After that new devices are added, and obsolete items can be deleted:

When devices are in the right collections again, advertisements will be functional again. These are all workarounds for managing obsolete clients in ConfigMgr. When there are more possibilities for managing them , I like to hear them. Managing obsolete clients stays a challenge this way!?

Update: You can also use a query on the client name to manage collection membership instead of direct allocations. That way the new clients appear in the same collections as obsolete ones automatically. (thanks to arricc)

Configure dynamic collections in ConfigMgr

After the success of my first blog "Creating dynamic collections in ConfigMgr" (most pageviews on this blog), I will write a follow-up on this item. It seems that many people are searching on this specific item, because there are no dymanic collections based on AD discovery data when installing ConfigMgr 2007. In this blog I will describe exactly what to do for having dynamic configuration. It must work this way!

First create new collections for all places there are systems in Active Directory OU's. When you have different OU's for desktops, laptops & specials for meaning, create collections for that systems also. It is also possible to bound user groups to it, which are useful for application deployment. I will write a new blog for App-V packages in ConfigMgr 2007 later on. On all of the collections you have the choice to configure systems or users/user groups.

  
I have created an "Virtual Machines" OU first. Now start a "Active Directory System Group Discovery". This can be found at Site Management > Site Server > Site Settings > Discovery Methods. This System Group Discovery must have the following settings: "Enable Active Directory System Group Discovery".

Choose the yellow star, and add the domain you are working with. In my case this is SystemCenter.com. First choose for the default AD settings: Local domain and Recursive will be default selected. It is also possible for selecting an specific OU, instead of complete discovery (see options below).

• Local domain: Browse for AD containers in the domain where the computer running the Configuration Manager 2007 console resides.
• Custom LDAP: Indicates that you want to browse for Active Directory containers. This option activates Browse.
• Recursive: Default. When selected, indicates that AD discovery searches child containers. Otherwise, child containers are not searched.
• Include groups: Not default. When selected, Active Directory discovery discovers objects within groups.

When choosing for Local domain (default option), the above screenshot will be displayed. Choose the Domainname for searching in all containers. The OU's with systems in it will be automatically recognized. (It is also possible for selecting an specific OU, instead of complete discovery).

On the tab "Polling Schedule" you can change the schedule option from 1 day to 1 hour or lower (best practice when using ConfigMgr 2007 R2). This because otherwise new Active Directory OU's will be synchronized once a day. With ConfigMgr 2007 R3 this is not needed anymore, so it doesn't have to be changed.

New in ConfigMgr 2007 R3 is "Enable delta discovery" which is default set on 5 minutes. This setting doesn't have to be changed, because this performs an intermediate discovery cycle adding only new resources to the ConfigMgr database. Choose also "Run full discovery as soon as possible" for recognizing Active Directory OU's immediately.

On the tab "Membership Rules" you can change the schedule option from 1 day to 1 hour or lower (best practice when using ConfigMgr 2007 R2). This because otherwise new systems will be synchronized to collections once a day. With ConfigMgr 2007 R3 this is not needed anymore, so it doesn't have to be changed.

New in ConfigMgr 2007 R3 is "Dynamically add new resources" which is default off. Choose to turn it on, because this allows you to more rapidly evaluate a collection membership by adding only newly discovered resources. Now open collection properties (in my case Virtual Machines), and click on the yellow (database) icon.

Give the query a name (in my case Virtual Machines) and choose for "Edit Query Statement". Let the option "Collection limiting" at default (Not collection limited), because when choosing "Limit to collection" not all the systems can be found.

When select OK a new windows will be opened. On the tab "Criteria" select the yellow star, and choose Select again (beneath "Simple value"). Choose here for the following options:

Fill in "System Resource" and "System OU Name" and select OK. In the next field choose Value (beneath "is equal to"). This will open a new window, with OU's recognized before (Active Directory System Group Discovery).

As you can see only 2 options are available. This because these are the only containers which contains systems. I choose "Virtual Machines" here, and select OK again. My Criterion properties has the following information now:

Choose OK multiple times now, and the configurating will be done. Now there is a new collection created, which is synchonizing from a Active Directory OU. When I choose Refresh, the systems in Active Directory will be automatically displayed in the "Virtual Machines" collection.

I hope you have enough information now for setting up a dynamic collection. When there are questions or other input, please add a comment to this blog, or contact me by e-mail.

MDT integration in ConfigMgr 2007

Last month I read at Twitter that someone didn't know that MDT could be integrated with ConfigMgr 2007. For me that was the reason for writing this blog about MDT and ConfigMgr. Yes, it's true that the intregation exists, and I will explain all the possibilities and benefits of it! When you are new with MDT or ConfigMgr, you can combine them for having the best of both worlds. Also with the knowledge you have (MDT and/or ConfigMgr) it will be a lot easier for using it.
 
When you using Microsoft products for deployment, you can choose between:
- Windows Deployment Services (WDS)
- Microsoft Deployment Toolkit (MDT)
  formely known as Business Desktop Deployment (BDD)
- System Center Configuration Manager (ConfigMgr)
 
While WDS and MDT are free of use; with ConfigMgr you must pay for every system you want to manage (client and/or server). In the projects I do, the choice is most of times made for ConfigMgr. This because ConfigMgr can do a lot more then MDT; and MDT will most of times be implemented for deployment only. Because MDT is customizable with build-in scripts, you want the same functionality in ConfigMgr actually! For this reason Microsoft created the integration for both products.
 

For having this functionality, install ConfigMgr and MDT (2010) on the same system. After that look in the Start Menu for Microsoft Deployment Toolkit, and start "Configure ConfigMgr Integration". Click Next, Finish, and start the ConfigMgr console again! Now you will have the following added features.
 
New Task sequences added:
The new Task sequences offers very useful deployment templates that are constructed using a new MDT wizard.
 

• Client Task Sequence: Creates a complete task sequence complete with additional task sequence elements.
• Client Replace Task Sequence: Creates a task sequence specifically for use when replacing hardware (capture user state).
• OEM Task Sequences (Pre- and Post-OEM): Creates task sequences  specifically designed for use with the hardware OEM.
• Microsoft Deployment Custom Task Sequence: Creates a task sequence that is essentially empty.
• Server Task Sequence: The server version of the Client Task Sequence with additional task sequence elements.
• User Driven Installation Task Sequence: UDI means that there is now an easy way to get users “involved” in an OS Deployment.

 
New options in existing Task sequences:
The new options offers additional environmental checks and data. This provides for prerequisite and safety checks before applying the image, and additional environment variables for use in customization.
 

• Use Toolkit Package: Takes care of getting the needed files to the computer (needed to use any other actions)
• Install Language Packs Online: Specify that package should be installed online (after the OS is running)
• Gather: Sets variables that can be used elsewhere in the task sequence (needed for dynamic deployments)
• Validate: Perform hardware checks to make sure the machine is capable, and prevent accidental deployment of client operating systems to server hardware
• Install Roles and Features: Install any available Windows Server 2008 (R2) role, role service, or feature
• Configure ADDS: Automates the DCPROMO process, and supports creating new forests, new domains, and new domain controllers
• Configure DNS: Define the zones that need to be created (Primary, secondary, stub, Integrated or standard)
• Configure DHCP: Define the scopes that need to be created (Address ranges, scope settings)
• Install Updates Offline: Apply patches to Windows before the OS boots for the first time (uses an existing software update package)
• Install Language Packs Offline: Specify that package should be installed offline (before the OS boots for the first time, similar to patching)

 
Create new Boot images:
This provides the ability to build customized Windows PE boot images, through a wizard added to the boot images menu item.
 

• Add extra folders and files to the boot image (example: Trace32 utility)

• Add support for additional databases in the boot image

At last you can use the build-in scripts that's included with MDT, for using in ConfigMgr 2007 Task sequences. With MDT integration in ConfigMgr 2007 you have the best of both worlds. And with new functionality in MDT 2010 Update 1 there is even more available! (User Driven Installation)
 
MDT 2010 can be used for Lite Touch Installation (LTI):
- Aligns with ConfigMgr
- Evolutionary refinements
- Adds server support
- Upgrade from BDD 2007 and MDT 2008
 
ConfigMgr 2007 (with MDT) is needed for Zero Touch Installation (ZTI):
- Fully integrated experience
- Single console
- Adds server support
- Extends and enhances ConfigMgr 2007

You can even have a dynamic computername filled-in, and place it in Active Directory in the right OU. In the customsettings.ini file (MDT) or Task sequence (set Task sequence variable) there must be an entry that looks like this:

- OSDComputerName=%SERIALNUMBER% to use SERIALNUMBER as computername

- OSDComputerName=%ASSETTAG% to use ASSETTAG as computername

It is also possible to use a script for it. With all of this you can have a dynamic deployment, without the need for manually actions!

Using Multicast functionality in ConfigMgr

By default ConfigMgr 2007 Operating System Deployment (OSD) is deploying in Unicast. Every deployment or software distribution will be bit by bit transferred to the device. With ConfigMgr 2007 R2, and specific configuration, Multicast is also possible. Then you can deploy maybe 50 or 100 devices at a time, without the data (bits) being transferred to every device for itself. It's good to know that you have a few possibilities in Multicast, and it's only working in WinPE mode. So what's the advantage of it, with Software distribution in the Task Sequences?

When you talk about Multicast in ConfigMgr R2, there are two types of it. There is a Autocast and Scheduled Multicast possibility. I will describe them both, and explain the differences between them.

Autocast: With Autocast the deployment will start on the first device. When you deploy another device (or more than one) the stream will also be transferred to the other device(s). When the first one is finished, the other device(s) must only pick the other bits for completion. The only thing you have to do for Autocast functionality, is enable Multicast. (screenshot)

Scheduled Multicast: With Scheduled Multicast the deployment will wait for a few minutes or number of clients. The deployment will then start when one of the two conditions are met. The idea behind this, that you have more time to prepare your devices. With this type of deployment the bitstream wil go once over the network, to all your machines that are ready! (screenshot)

For Multicast to get it working, there is a Distribution Point and the Transport server in Windows Deployment Services (WDS) needed. When both are installed and enabled on a Windows 2008 Server, the configuration in ConfigMgr 2007 will take place.

Distribution point: In the ConfigMgr Distribution Point properties you must enable the setting "Allow clients to transfer content from the distribution point using BITS, HTTP and HTTPS". Also on the Multicast tab you must enable the "Enable multicast" setting. Have also a look on the Transfer rate possibility. Ideally this must be set to 100 Mbps or 1 Gbps for a good transfer speed.

When you also want to make use of Scheduled Multicast, you must enable the setting "Enable scheduled multicast" and set the Session start delay (# minutes) and the Minimum session size (# clients). When one of two are met, the deployment will be started (one bitstream).

Image deployment: When you want a succesfull Multicast deployment, the default WIM image must also be Multicast enabled. Open the properties of the WIM image (example: Windows XP SP2), and enable the setting "Allow this package to be transferred via multicast". You can also see here that Multicast functionality is only possible with WinPE (so during the first part of deployment).

When you don't want any Unicast deployment, enable also the setting "Transfer this package only via multicast". Then you are sure that Multicast will be used! Because this will only works in WinPE, there isn't any need to enable this setting on your Software packages. Now there only must be set an advertisement to get it work.

Advertisement: In the advertisement enable the setting "Download content locally when needed by running task sequence". When this is set on: "Access content directly from a distribution point when needed by the running task sequence", Multicast deployment will not work.

Deployment: These are some pictures displayed during deployment. The first one is captured during deployment in Autocast; the second one is captured during Scheduled Multicast.

Because Multicast works only in WinPE mode, you have the choice to put your applications in the default WIM image. Not installing them, but only put the source in it. Then you are still flexible, and make use of full Multicast functionality! Otherwise a part of the installation will be in Multicast, and the other part (applications) will not.

In the Task Sequence don't add your packages with "Install Software", but choose for "Run Command Line". Then put in there the command which is normally placed in Programs - Command Line, for unattended installation. For get it working place the location (e.g. C:\Apps) before the command, and the application will be installed from the local source.

That's all about Multicast for now!

ConfigMgr 2007 Troubleshooting issues

Everybody knows there are some challenges when installing, configuring and managing ConfigMgr 2007. With SMS 2003 that was the same, a great product when it works, but a lot of frustration when it doesn't. I personally think ConfigMgr 2007 does work a lot better then SMS 2003, but still there are some challenges. In this blog I will define some of that challenges, and how I resolve them. Also I will put some handy URL's for troubleshooting, so your ConfigMgr environment will function a lot better! In my other blogs I declare what to do with driver management and migrating collections. Now I go further and treat the rest.. These are all real live situations, so take it to your advantage!

First of all you must put your network drivers in the boot images, because otherwise deployment will not work at all. This must be the newest drivers with support for WinPE OS. Best practice is using the x64 boot image for Capturing images, and the x86 boot image for Deploying images. Also Trace32 is a nice utility (available since SMS 2003) for putting in the boot images. When reading logfiles you can do it better in Trace32 and not in Notepad. Have a look for yourself, and you know what i mean. There is no Trace64 utility at the moment, so you must do it with the older one. Trace32 will become very handy! Remember that it's only functional in a x86 environment. For x64 troubleshooting you must put in on a share, and open the logfile on a x86 device, with trace32 installed. More about logfiles in my next blog!

Also check if the packages (listed in the Task Sequence) are available on the Distribution point. Otherwise deployment will fail also. When using Multicast, ConfigMgr 2007 R2 and specific configuration is needed. Because Multicast works only in WinPE mode, you have the choice to put your applications in the default WIM image. Not installing them, but only put the source in it. Then you are still flexible, and make use of full Multicast functionality! Otherwise a part of the installation will be in Multicast, and the other part (applications) will not. I will write a blog about Multicast later, so stay tuned for that one!

Now some other Troubleshooting issues! When deploying an image on the same device many times (for testing possibilities) deployment will fail with abortpxe.com. This because Windows Deployment Services (WDS) cannot handle that, and must have a reset. The best thing you can do is resetting the WDS service on the ConfigMgr server. When this is not the solution you must stop the WDS service, deleting the PXEBootFiles folder and all other PXE folders and files in C:\Windows\Temp and start the service again. When it's still not working, then your object is obsoleted in the collection. For solving that add an "Membership rule" on the specific collection (blue computer icon), and choose the following:

(Where Value is your computername) On the next setup page "Collection Limiting" choose No collections and go further. On the next setup page "Select Resources" choose all devices you see (mostly two i think). When back in the collection delete the object that is obsolete. Then deployment will work finally again! When advertising a Task Sequence (or something else) you can choose between mandatory deployment or not. For testing possibilities it's better for choosing No mandatory deployment. Otherwise you must remove the PXE Advertisement (screenshot) after each try. The above steps are needed because WDS cannot handle re-imaging of devices within one hour. There is a way for shorten the delay, but default it will be one hour.

The way for that is installing a Microsoft hotfix and modyfing a registry key. The hotfix can be found at: http://support.microsoft.com/kb/969113
(Operating system deployment fails in a System Center Configuration Manager 2007 SP1 environment if you deploy a different operating system to a client within one hour of a previous deployment).
This hotfix is not needed anymore when you installed ConfigMgr SP2 in your environment.

The registry key which must be changed can be found at: [HKLM\Software\Microsoft\SMS\PXE\CacheExpire] or when using a x64 device it can be found at: [HKLM\Software\Wow6432Node\Microsoft\SMS\PXE\CacheExpire].
Change the value from 0 tot 180 decimal (0x000000b4); this changes the default 60 minutes to 3 minutes (another value is also possible).
Microsoft explanation: http://support.microsoft.com/kb/2019640

For questions or improvements please put some comments on this blog!

New functionality in ConfigMgr 2012 (vNext)

Now ConfigMgr R3 is released we must wait for ConfigMgr v.Next to get new functionality. Here is a (small) list of changes between ConfigMgr 2007 and v.Next:

• While ConfigMgr 2007 is 32-bit, v.Next is 64-bit Native only! (some may require W2k8 R2)
• Mobile Device Manager is built-in (so the product itself doesn't exist anymore)
• SQL Server 2008 64-bit is required for the ConfigMgr database!
• SQL Reporting Services is the only reporting platform, instead of standard reporting
• Distribution groups are added for administrative purpose
• The default "All" collections is minimized to All Systems only!
• Advertisements are renamed into Deployments (and positioned better, because they were beneath Software Distribution in 2007)
• Improvements to OS Deployment and Remote Control (now possible with the usage of CTRL-ALT-DEL)
• There are some new System roles in it: Software Catalog Web Service Point, Software Catalog Web Site Point, Mobile device enrollment proxy point, Mobile device enrollment point (because of Mobile Device Manager functionality)
• A migration from ConfigMgr 2007 will be a clean install, not an in-place installation!
• Desired Configuration Management and Asset Intelligence roles are integrated into a “Assets and Compliance” tab
• Software Updates auto-deployment (including Forefront definitions)!
• The product is more user-based instead of computer-based! (e.g. software distribution to users)
• And last but not least: v.Next looks like a real System Center product, and not like SMS 2003 ;o)

The product itself will be available end of 2011, so that takes another year! In the meanwhile we can play with the Beta version, so more information is on it's way!

Creating dynamic collections in ConfigMgr

When designing a new ConfigMgr environment, there is not only a total design needed but also a plan for the collections. I let my decision mostly be based on what functionality is needed, and if Active Directory is leading or not. This because you can create collections on many different ways, and advertisements can only be set on collections. So when you advertise an operating system, application or software update it will be bound to a collection. For OS deployment you can create additional colllections, but what to do with the other ones? The most used way is bound the collections to Active Directory OU's. In that way Active Directory is leading, and it will synchronize objects to ConfigMgr collections. I will explain here what to do, and how to bind them to Active Directory.

After installation of ConfigMgr there are a lot of default collections, but they are not always handy and useful. You can move this default collections to a new one, so there not in sight all the time. Now it's better to create your own collections, so you can decide which devices to put in your collections. There is a query needed for bounding collections to OU's, but first you must create these collections. You can do this manually, or there is also a way for importing them from Active Directory. The tool needed for that is named "SCCM OU Collection creator". This tool can be download here:

http://www.sccm-tools.com/tools/standalone/sccm-ou.rar.

With this tool you can create many collections at once, and the good news is it will be automatically bound to Active Directory OU's. Because you want to move these collections afterwards to another location, there is another tool needed, The tool needed for that is named "CollTree for SCCM". This tool can be download here:

http://myitforum.com/cs2/blogs/bleary/attachment/68439.ashx.

This tool is even compatible with SMS2003 collections, and it will become very handy. Okay, now the collections are imported, moved, and there is an query on it. But how to set a manually query on the collections? The command for that is not that difficult. First create a new collection, and open the properties of it. On the tab “Membership rules” create a new SQL query, and choose System Resource & Edit Query Statement, then select the Criteria tab. Choose New Query and fill in the following properties: 

Choose OK after that. Now you must decide how fast collections will be synchronized. Default the collection will be synchronized within 1 day. Because it can be to slow to have the objects in Active Directory synchronized with the collections, you can shorten the schedule to 1 hours, or even 15 minutes. Better is it to choose for the new R3 update, because collections will synchronized must faster then before. I will post that new functionality later. This is all you have to do for having dynamic collections in ConfigMgr.

ConfigMgr 2007 R3 is here!

Sooner then expected, but even a long wait: ConfigMgr 2007 R3 is here! This will be probably the last release for ConfigMgr 2007, because the next release is now available in beta. Which improvements will R3 bring to us, and is it worth it for installing the update? The answer is Yes, because there are some cool things in this release. Below is a quick summary of what’s new with R3:
  

Centralized Power Management
Configuration Manager R3 lets IT organizations centrally manage the power settings of Windows 7, Vista and XP computers, helping reduce energy consumption and costs. You can plan and apply a power management policy for high and low PC usage periods, monitor user activity to avoid any productivity interruptions and correct non-compliance. Detailed reports of trends and settings help you make smart power management choices, and also validate Green IT projects with summaries of power, money and CO2 savings.

Mobile Device Management
Configuration Manager R3 includes licenses for the popular System Center Mobile Device Manager, so you can run comprehensive asset inventories, deploy software, manage settings and enforce password policies for Windows phones.

Enhanced Scalability and Performance
Configuration Manager R3 is more scalable than ever, increasing the number of supported clients to 300,000 per site. R3 is also more efficient in the way it communicates with Active Directory, helping you discover user or machine changes more quickly and allowing custom queries to define user, system or group attributes.

Finally, it is worth noting that, just like Configuration Manager R2, R3 will be the foundation for the upcoming Forefront Endpoint Protection 2010. By bringing endpoint security into overall endpoint management, you can reduce costs and inefficiencies, and also improve security and compliance.

Especially the Power Management integration, and communication with Active Directory (which will be must faster), are useful functionality. Also the right-click tools are not necessary anymore for putting clients in a collection. This because R3 has this functionality build-in now. Right-click on a collection you want to manage and there is a new option available, "Add Resource". It is also possible to right-click a resource like a computer and use “Manage Collection Membership” to add it to a collection. Really useful!

Driver management in ConfigMgr 2007

One of the difficult things in deployment is getting all drivers to work. Best practice here is to remove the "auto-apply drivers" in the Task sequence, and put "add driver package" instead. Most of the time when i'm import drivers, i give them a tag-name for the model. In that way you can easely update or remove a model later. There is also an option for creating folders in it. Bad thing is you can't import a driver multiple times, so that's not a good idea after all. Also the search folder will be a good idea actually.. In that way the folders are query based, so you can seperate the drivers in different folders.

For getting the right driver package on a system, you must put a condition on the driver packages. The most implemented way is by model name of the systems. The command for getting that is by CMD.exe - WMIC /Node - CSProduct Get Name. The result for that command must be placed in the condition of the driver package. The rule for that is "SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" where %<MODEL>% must be replaced with the actual model name. Now you are ready for deploying many types of systems with different driver packages.

But what to do with drivers that are not installed after deployment? There are drivers that won't be installed on the system, whatever you do. For solving that look at the option for creating a software package. If there is a setup-file in that specific driver folder, you can do an unattended install, and put it in your Task sequence. Now you will see that every single driver will be installed. For boot images it's the best to work with the newest NIC drivers for getting it to work. Now you can truly enjoy the "one image" functionality!