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?!

Handy tips and tricks for ConfigMgr deployment

For multiple years I am busy now with (client) deployment, delivering applications, configuring policies, and a lot of troubleshooting. This with many products, on both fysical and virtual systems. For example:

• System Center tools: Configuration Manager (SMS, SCCM), Operations Manager (MOM, SCOM), Essentials, Updates Publisher (SCUP), Server Updates Services (WSUS)
• Deployment tools: Ghost Server, Deployment Services (WDS), Deployment Toolkit (MDT) Configuration Manager (SMS, SCCM), Altiris Server, Wyse Device Manager (WDM)
• Knowledge of: Desktop Optimization Pack (MDOP), VMware View (VDI), RES PowerFuse, RES Wisdom, Group Policy Objects (GPO), Group Policy Preferences (GPP)

When doing (client) deployment in ConfigMgr 2007, you can have a lot of challenges. A few of this challenges I will describe in this blog. When having questions on a specific deployment issue, write a comment on this blog.

Here they are (most of them i've seen during the last few months):

1. When deploying a device multiple times during a "capture and deploy" Task Sequence, and a abortpxe.com error message is displayed, delete the obsolete object in the specific collection, and add the new object again. Most of times there will be two objects with the same name. (where one will be obsolete)
2. When deploying a device multiple times, and startover again within 15 minutes, there will be a error message displayed. This is default WDS (Windows Deployment Services) behaviour, and can be solved with restarting the WDS service.
3. When creating a new Windows image from source files, put the auto-apply drivers or apply driver package step before the "Apply Operating System" step. Otherwise specific drivers (SATA disks for example) will not be functional when booting from disk.
4. When distributing a Windows image (WIM file), put the auto-apply drivers or driver package step after the "Apply Operating System" step. Otherwise an error will follow, and Task Sequence fails.
5. When using multiple driver packages for one single Windows image, put a WMI query on it. With the query SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" you can decide which driver package belongs to which system.
6. When drivers or driver packages are not installed during deployment, add an extra line in sysprep.inf which contains "UpdateInstalledDrivers=Yes" to make it work again (Windows XP solution).
7. When putting Software Updates in the Task Sequence, and the system is not yet domain member, add the next lines to the "Setup windows and ConfigMgr" step (SMSSLP=SERVERNAME.FQDN.COM SMSMP=SERVERNAME.FQDN.COM)
8. When Software Updates are not installed during the Task Sequence, change the advertisement at Download Settings > Slow network boundary from "Do not install updates" to "Download software updates from distribution point and install".
9. When build and capture Windows 7 in ConfigMgr, don't add a product key in the Task Sequence (Apply OS step). Otherwise it fails with error 8004005 and exit code 31. This because the product key and product will not match then!
10. When access to a remote share (distribution point) is not working, then additional rights are needed. The server which is your Primary site server is the one which needs to go to the source folder. This account needs to have at least Read rights to the network share, and read NTFS rights to the files/folders on that share.
11. When a "PXE-E32: TFTP open timeout" error message is displayed during PXE network boot, import the device manually in ConfigMgr, or activate "Unknown computer support" feature.
12. When "Program Files cannot be located on a Distribution point" error message is displayed during loading the boot image, select "When no local distribution point is available, use a remote distribution point" in the advertisement.

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?!

Troubleshooting Task Sequences

In my last blog I explained some Troubleshooting issues in ConfigMgr 2007, especially foccussed on Windows Deployment Services (WDS). But what to do when the Task Sequence is running, and you get an error during deployment? This blog will help you troubleshooting on that part!

During the time your Task Sequence is running; where to find the logfiles when it goes wrong? First of all enable "command prompt support" on both boot images. This enables pressing F8 during deployment in the WinPE stage. This will become very useful when troubleshooting deployment issues. This because you can open the various logfiles, access network shares or try to ping/access your Distribution point(s).

During installation the smsts.log file is located at different places. Everytime the device is booted again while the Task Sequence is still running, the smsts.log will be copied to a smsts--.log file, and a new smsts.log file will be created.

1. System booted in WinPE and the local harddisk is not modified (smsts.log in the "x:\windows\temp\smstslog" folder)
2. System booted in WinPE and the local harddisk is partitioned and formatted (smsts.log in the "x:\smstslog" folder and after that in the "c:\_SMSTaskSequence\Logs\Smstslog" folder
3. System booted in Windows before the ConfigMgr client is installed (smsts.log in the "c:\_SMSTaskSequence\Logs\Smstslog" folder)
4. System booted in Windows after ConfigMgr client is installed (smsts.log in the "c:\windows\system32\ccm\logs\Smstslog" folder)
(When using a x64 device, you can find it in the "c:\windows\SysWOW64\ccm\logs\Smstslog" folder)

From this point you can examine the smsts.log in order to find out what went wrong. The messages displayed give you mostly a good idea on where to start looking.

When watching these logfiles; Trace32 is the recommended way. This because Notepad will not dynamicly update the information you see, and Trace32 will do that for you. Also any warnings are displayed in yellow, and any errors are displayed in red. In that way you have a quick view what's wrong during deployment. Remember that trace32 only works in a x86 environment, so for the x64 boot image it will not work. Then you must copy the logfiles to a fileshare, and open it from another x86 machine with Trace32 installed on it.

For error solving there is an additional option to look for error codes. This can be found in Trace32 - Tools - Error lookup. Now you are ready for true troubleshooting in Task Sequences! Trace32 is part of the "System Center Configuration Manager 2007 Toolkit V2" and can be found here: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=5a47b972-95d2-46b1-ab14-5d0cbce54eb8

----------------------------------------------------------------------

The following list provides specific information about each tool in the toolkit.

• Client Spy - A tool that helps you troubleshoot issues related to software distribution, inventory, and software metering on Configuration Manager 2007 clients.
• Delete Group Class Tool - A tool used to remove inventory group definitions along with history data, tables, views and stored procedures for the group.
• Desired Configuration Management Migration Tool - A tool used to migrate from the DCM Solution for SMS 2003 to DCM in ConfigMgr 2007.
• Desired Configuration Management Model Verification Tool - A tool used by desired configuration management content administrators for the validation and testing of configuration items and baselines authored externally from the Configuration Manager console.
• Desired Configuration Management Substitution Variable Tool - A tool used by desired configuration management content administrators for authoring desired configuration management configuration items that use chained setting and object discovery.
• Management Point Troubleshooter Tool - A tool that checks a computer system before and after a management point installation to ensure that the installation meets the requirements for management points.
• Policy Spy - A policy viewer that helps you review and troubleshoot the policy system on Configuration Manager 2007 clients.
• Preload Package Tool - A tool used to manually install compressed copies of package source files on Configuration Manager 2007 sites.
• Security Configuration Wizard Template for Configuration Manager 2007 - The Security Configuration Wizard (SCW) is an attack-surface reduction tool for the Microsoft Windows Server 2008 R2 operating system. Security Configuration Wizard determines the minimum functionality required for a server's role or roles, and disables functionality that is not required. The Configuration Manager 2007 Service Pack 2 Security Configuration Wizard template supports new site system definitions and enables the required services and ports.
• Send Schedule Tool - A tool used to trigger a schedule on a Client or trigger the evaluation of a specified DCM Baseline. You can trigger a schedule either locally or remotely.
• Trace32 - A log viewer that provides a way to easily view and monitor log files created and updated by Configuration Manager 2007 clients and servers.

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!