More handy tips and tricks for ConfigMgr deployment

Because there are many challenges to control in ConfigMgr, I will post another blog about handy tips and tricks! This time I will order them on subject, so it's easy to find the right one! Everyday there are new challenges in ConfigMgr, but still it's a cool product. This because when it works, it can do a lot for you. And with new releases and updates it can even do more!

Here the new tips and tricks section:

Windows XP:

• With Windows XP your image is not that big (500Mb), but many Driver packages are needed (for every device a driver package). Put all Driver packages in the Task sequence, with a query on it. That way you can have a single image, single Task sequence, for many different devices.
• Because Windows XP don't recognize SATA disks by default, put SATA drivers in the Driver packages, and select the right model in the Task Sequence! That way it's not needed to change the BIOS setting from AHCI to ATA/IDE or something like that.
• Most of time I create a Sysprep package (extract files from deploy.cab), and put the sysprep.inf file in the Task sequence. That way you are flexible, and put desktops and laptops in their own OU's!
• For having Multicast functionality with maximum results, put the source files of applications in the image. That way you're still flexible with a clean image and sources (image gets bigger), and data goes only once over the network. This because Multicast only works in WinPE mode.
• Because there are so many Software updates after Windows XP SP3, update your image with as many updates that's possible. That way deployment goes faster, and less updates needs to be installed during or after deployment. For example: only install Office updates during Task sequence progress.

Windows 7:

• For creating Window 7 images, it's not necessary to add a product key in the Tasks sequence. Otherwise capturing the image will fail. The product key must be placed in the unattend.xml file, so installation can choose which Windows 7 version must be installed.
• With Windows 7 no large driver packages will be needed anymore. This because there is a large driver library build-in, and only specific (older) drivers must be manually added. Windows 7 is easy to install that way!
• Using sysprep, and creating a sysprep package is not necessary anymore. Just create a unattend.xml, and Windows will automatically run sysprep during deployment. Again: Windows 7 is easy to install that way!
• More tips and tricks for Windows 7 will follow later!

Software Updates:

The combination of ConfigMgr and Software Updates is not always a simple one. This because when it's not working, it's not always easy to find the solution. Here are some best practices for installing and configuring:

• When installing WSUS, choose always for a custom website, with ports 8530 and 8531. This way the ConfigMgr Management Point and Software Updates are not both configured on port 80 and 443 (best practice).
• When WSUS is installed, check permissions on the WSUS and WSUSContent folder. On both folders the Network Service account must have the right permissions. On the WSUS folder set Read permissions and on the WSUSContent folder set Full Control permissions for the Network Service account.
• When WSUS is installed with a custom website check security on the IIS website. This must be set to Anonymous authentication, with a "IUSR_<ConfigMgr Server>" account. This must be a Domain User account, with Local Admin rights on the ConfigMgr server.
• With MP Troubleshooter (ConfigMgr 2007 Toolkit) you can check if the IIS account has enough permissions for accessing both websites. It's always necessary for having enough (local) rights on the ConfigMgr server.
• Sometimes a Proxy server must be used for synchronizing updates. Try both configurations (on and off) with or without an User account. Sometimes there must also made a bypass on the Proxy server for getting it to work.
• At last, do a "Run Synchronization" on the Update Repository and follow the Software Updates in the wsyncmgr.log (easy to see with SMS Trace - ConfigMgr 2007 Toolkit). When synchronization is done, do it again till no updates are available anymore. Then create Search Folders.
• With Search folders it's easy to see which updates has come available for the last month (example) for a specific product. This updates can be drag-and-dropped on the Update Lists for creating overviews.

Driver Management:

• When importing drivers, only once a specific driver can be imported. With that knowledge it's not possible to create a specific folder for every hardware model. What i do most of time, is put a label (tag) on drivers, with the model number.
• When creating driver packages it's possible to have a mix of drivers (multiple hardware models). This because a specific driver can be imported once, and that driver must be available for multiple hardware models (for example).
• There is a hotfix available for importing drivers multiple times, for creating specific driver packages. This hotfix can be found at: http://support.microsoft.com/kb/2213600
• When using Dell systems, it's easy to using the "Dell Client Deployment Pack". Then the only thing you have to do is importing the CAB files, and Dell will create the driver packages for you!
• When using Dell systems, you can update or change BIOS settings with the "Dell Client Configuration Utility". Both downloads are plug-ins for ConfigMgr 2007, and will be visible in the console.
• On the Microsoft Update Catalogue, drivers can be found on specific names, or with Hardware ID's like the following:
  "PCI\VEN_14E4&DEV_1677&SUBSYS_01AD1028". Just look in the details from drivers you want a specific driver for.

Service accounts:

• There are two (2) service accounts needed, when using ConfigMgr the right way. The Network Access (NA) account, and the Push Installation (PI) account. Both accounts can have Domain User rights, but the PI account must at least Local administrator on the device then.
• When setting up ConfigMgr with minimal (Domain User) security rights, more time is needed for setting up the server(s). This because sometimes the service accounts are used, and sometimes the Primary server computeraccount is used.

Access to remote share:

• The server which is your primary site server role is the one which needs to go to the source folder. So, the computer account in Active Directory for your primary site server is the account which needs to have at least Read rights to the remote network share, and read NTFS rights to the files/folders on that share.

Again, these are a few most common error messages and best practices during Task Sequence deployment in ConfigMgr. When having questions on a specific deployment issue, write a comment on this blog.

That's all for now, more tips and tricks later?!