ConfigMgr 2007 Standard distribution point migration

During a ConfigMgr 2007 distribution point migration IIS must be installed (if it isn't installed yet) and content can be converted. Because of IIS installation (which ConfigMgr will do for you, if you select this in the wizard) a restart may be triggered. In my case an unexpected restart was done on a Windows Server 2008 R2 system. This because of an "unknown" MSI installation. As far as I can see only the "Remote Differential Compression" (RDC) feature is installed and the "Microsoft Visual C++ 2010 x64 redistributable".

When distribution points are not "eligible for upgrade", which they were in my case, just make sure no other roles (eg PXE service point) then distribution point are installed. Just make sure there is enough available disk space also - need 100% free space in order to carry out conversion to ConfigMgr 2012 content library. When removing PXE service point, clean up disk space, and wait a while (or reboot the server), distribution points are finally eligible for upgrade.
Source: Microsoft TechNet

When looking in SMS_DP$\SMS\BIN\vcredist.log-MSI_vc_red.msi on the server the following lines are displayed:
MSI (s) (68:4C) [10:55:25:452]: Note: 1: 1707 MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010  x64 Redistributable - 10.0.40219 -- Installation completed successfully.
MSI (s) (68:4C) [10:55:25:452]: Windows Installer installed the product. Product Name: Microsoft Visual C++ 2010  x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
MSI (s) (68:4C) [10:55:25:452]: Value of RebootAction property is MSI (s) (68:4C) [10:55:25:452]: Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010  x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010  x64 Redistributable - 10.0.40219. Restart required. The installation or update for the product required a restart for all changes to take effect.  The restart was deferred to a later time.
MSI (s) (68:4C) [10:55:25:468]: Deferring clean up of packages/files, if any exist MSI (s) (68:4C) [10:55:25:468]: MainEngineThread is returning 3010 MSI (s) (68:34) [10:55:25:468]: RESTART MANAGER: Session closed.
MSI (s) (68:34) [10:55:25:468]: No System Restore sequence number for this installation.

When looking in Event Viewer the server is rebooted a second afterwards (on 10:55:26 exactly):
The process f:\06ce98a1da047515c72afeca1f47e3\Setup.exe (########) has initiated the restart of computer ######## on behalf of user ######## for the following reason: Other (Planned)  Reason Code: 0x80000000  Shutdown Type: restart
So yes, "Microsoft Visual C++ 2010 x64 redistributable" did need a restart, and your server will be down for a few moments.

Furthermore Microsoft TechNet mentions that the ConfigMgr 2007 client must be removed on Branch distribution points only. During migration on a Standard distribution point however the following message is displayed "Failed to update binaries". After removing the ConfigMgr 2007 client, converting content was done successfully without any problem. When migrating packages is done, the following message is displayed: "Completed reassign distribution point". So next time, I will remove the ConfigMgr 2007 client on Standard distribution points before migration also.

Be aware that only packages which are migrated to ConfigMgr 2012 will be converted to the SCCMContentLib folder. Other old packages will still be left in the old package share folder and can be removed afterwards manually. Just make sure that packages migrated does not have the "Copy the content in this package to a package share on distribution points" have selected in properties. Otherwise they will be on your new ConfigMgr 2012 server in package share folder also. After that you will have new distribution points running!

Source: Microsoft TechNet

ConfigMgr 2012 Beta 2 with App-V integration

In ConfigMgr 2007 with R2 it was possible to import App-V packages and stream them to the end user. There was also the possibility to choose between streaming or local delivery for that. Have a look at this blog for more information about ConfigMgr 2007 with App-V integration: http://henkhoogendoorn.blogspot.com/2010/12/configmgr-2007-with-app-v-integration.html

Because of multiple reasons there was the choice between App-V integration in ConfigMgr 2007 or using the stand-alone App-V solution. I have selected a few websites with more information about that:

• App-V 4.6 and ConfigMgr 2007 SP2: even better together
• How to integrate App-V with SCCM without losing the features you care about
• Integration App-V and SCCM
• SCCM / App-V hybrid architecture
• App-V - Introduction, Components and SCCM Integration
• SCCM and App-V Integration Whitepaper

Personally I think that the combination of ConfigMgr 2007 and App-V is quite good, only it's better to keep them seperate. This because it's a bit slower in ConfigMgr and there's no publishing functionality in it. That way you must decide where to put the shortcuts in the App-V package, during sequencing. Also all shortcuts will be displayed on the desktop or in the start menu after publishing; no changes on that possible.

The advantage of putting App-V packages in ConfigMgr 2007, and using a Distribution Point (DP) for streaming is integration. No need for having App-V Management and/or Streaming servers that way. Just configure the (existing) ConfigMgr server and deploy all your applications from one platform! The only App-V installation needed is the Sequencer for creating App-V packages. Instead of multiple App-V servers, more Distribution Points are recommended then.

Now have a look at the combination of ConfigMgr 2012 Beta 2 and App-V. In ConfigMgr 2012 things are quite different. Open the ConfigMgr console, Select Application Management, rightclick on that and choose Create Application. There are four (4) choices now, with Microsoft Application Virtualization in here also. Just import a already sequenced application here.

When looking in the Applications screen there are no orange App-V icons anymore. On every application there are tabs for Deployment Types and Deployment (first known as advertisement). On deployment types there are new Content settings seen:

• Persist content in the client cache
• Enable peer-to-peer content distribution
• Load content into AppV cache before launch

Default settings for fast or slow/unreliable network boundary:

• Fast > Download content (changed to Stream content in my environment)
• Slow/unreliable > Do not download (changed to Download content in my environment)

On the Publishing tab, which is also new in ConfigMgr 2012, shortcuts can be selected. Keep in mind that the location (desktop and/or start menu) cannot be set, so still this must be decided during sequencing. The shortcuts that will be displayed on the desktop or in the start menu can be selected now!

For streaming App-V packages from Distribution Points no further configuration is needed in ConfigMgr 2012. Distribution Points have streaming functionality by default now. For App-V integration on the desktops an App-V 4.6 SP1 client is needed. No further configuration is needed on that also. Sometimes the Cache will be placed on another drive, and the Cache size will be enlarged. The file type extensions will be automatically associated to the new applications.

New applications available from ConfigMgr 2012

File type extensions are automatically associated

That's all you need to have for App-V integration in ConfigMgr 2012. Because off better user support in ConfigMgr 2012, App-V integration will be a more interesting choice now!

ConfigMgr 2007 with App-V integration

With ConfigMgr 2007 Release 2 (R2) it is possible to add App-V packages to the ConfigMgr console, and advertise them to ConfigMgr clients. With that functionality, no additional App-V Management or Streaming server is needed anymore. Now there is one solution for managing and publishing MSI-based & Virtual-based applications! I will explain in this blog what to configure in the ConfigMgr console, and how the App-V packages will be published to the ConfigMgr clients.

How it works?

ConfigMgr 2007 supports running sequenced applications created using the App-V Platform. App-V packages are running on ConfigMgr 2007 clients without having to install applications on the computer. Target computers must be running Windows XP (or above) to run virtual application packages. After you create a sequenced application using the App-V Sequencer, you must import the package into ConfigMgr 2007 and deploy the App-V package to ConfigMgr 2007 clients.

First you must make sure you are running ConfigMgr SP2 and R2 or R3 for having fast App-V package delivery. While Release 2 (R2) is needed for App-V functionality, Service Pack 2 (SP2) is needed for fast App-V package delivery. Because with ConfigMgr SP1 it could take up to 10 - 15 minutes for having the App-V packages available, while with SP2 there is almost no delivery delay! With ConfigMgr SP2, delivery can be as fast as with App-V streaming server, which is a great feature!

Client setup

On the computer there is a ConfigMgr client and a App-V client needed. There is no additional configuration on the App-V client needed. You need to enable Virtual Application Deployment in ConfigMgr, and ConfigMgr configures the App-V client for you. Any existing policies will be overruled. Best practice is to put the ConfigMgr client and App-V client in the Task sequence, which is used at deployment. Otherwise App-V delivery is not possible.

ConfigMgr 2007 setup

I will describe here which configuration is needed in the ConfigMgr console. These are all needed for having App-V functionality in ConfigMgr 2007.

Warning: this approach will affect every App-V client with the ConfigMgr client connected to the site. This because App-V management in ConfigMgr will overrule the existing App-V configuration.

In the ConfigMgr Distribution point properties (General) choose for "Allow clients to transfer content from this Distribution point using BITS, HTTP, and HTTPS"

In the ConfigMgr Distribution point properties (Virtuall Applications) choose for "Enable virtual application streaming"

At last, in the Advertised Programs Client Agent properties (General) enable "Allow virtual application package advertisement"

Because ConfigMgr supports two types of App-V delivery (streaming and local delivery), you need the above setting. Streaming delivery is simular to App-V streaming server and uses HTTP(S). Local delivery does "download and execute" the App-V package using BITS (same as MSI-based applications). With local delivery the App-V package will be saved on the computer, and is alltimes available (same as MSI-based (installed) applications)! Streaming is recommended on (VDI) desktops or fat clients.

App-V packages

In the ConfigMgr console you can add MSI-based & Virtual-based applications. I will describe the steps for adding App-V packages here.

Right-click on Software Distribution - Packages and choose for New > Virtual Application Package. Find the XML file, and add the App-V package.

Create an (sub)Collection for every application you want to advertise. Create a Active Directory group for every application, and add it to the collection.



Create an advertisement for every application you want to distribute, and add it to the collection with the same name. Choose for the following settings:

• Schedule: Mandatory assignments (occurs on current date/time)
• Distributing points: Stream virtual applications from Distribution point
• Interaction: Allow users to run the program independently of assignments

While sequencing choose for leaving icons in the Start menu and/or on the Desktop. This because no App-V Publishing server will be available, and users will see no icons to start the application.

Results on the computer

When all of the above steps has been set, App-V delivery will be available. On the ConfigMgr client there will be a policy refresh everytime you logon. At that point the App-V package will be available after 5 - 30 seconds. This will depends on sizing and configuration of the ConfigMgr server.

Again more functionality becomes available in the ConfigMgr console!

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!

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!

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!