Configuring the Source Hierarchy

The first step in configuring the migration process is to “Specify Source Hierarchy.” This is both crucial and required in order to move forward with the migration plans. Specifying the Source Hierarchy allows ConfigMgr 2012 to gather all of the necessary data from SCCM 2007 in order to identify the objects that can be migrated.

Let’s go ahead and walk through this process. All of the migration tools are located under the administration section of the console.

Expand the Migration folder to reveal three options.

• Source Hierarchy
• Migration Jobs
• Distribution Point Upgrades

Either right-click on “Source Hierarchy” or from the ribbon, select “Specify Source Hierarchy.”

The first page of the Source Hierarchy wizard is now presented and there are a number of things to be configured. In order to properly acquire all of the information from the SCCM 2007 environment, it is necessary to start by specifying the top most level primary site. In most cases, the top level primary site in an SCCM 2007 hierarchy is a Central Primary.

With the Top-level Configuration Manager 2007 site server specified, the access accounts will need to be configured. As noticed in the screen shots, the necessary permissions have been laid out already.

• Read access to the SMS Provider.
• Read & Execute on the source site SQL Server

As with most SMS Providers access the account being specified will require Distributed COM Users permissions within AD. Microsoft outlines on TechNet that when specifying a computer account this permission is required, but I would recommend that you validate this access even when using a domain user account.

Once all of the accounts have been entered and “OK” has been selected, the data gathering process will immediately start. A progress window will appear showing the steps of data gathering.

If an error occurs during the data gathering process, nine times out of ten it is permission related. The ratio may indeed be even higher but we’ll go with 90% for now. Once the initial data gathering process has been completed the status of the Source Hierarchy will show a status of “Ready for next gathering process.”

The Migration Job

With the Source Hierarchy data gathering complete it is now possible to move into the actual migration of objects. In order to begin migrating any data from SCCM 2007 we must first create a migration job. From the Migration section either right-click or use the ribbon and select “Create Migration Job.”  This will start the migration job wizard.

There are three types of migration jobs…

• The Collection Migration option is the most comprehensive. When using this type of migration job it is possible to select associated items such as packages and advertisements that are targeted at the collections in question. Advertisements cannot be migrated outside of the collection migration job. Also, when migrating collections both maintenance windows and collection variables will be transferred. However, AMT client provisioning data cannot be migrated.
• Object Migration will allow for the migration of all the items outside of collections. Please refer to Part 1 of this blog series for a list of the objects available for migration.
• The last option, Objects modified after migration, has a rather specific purpose. As the migration of all SCCM 2007 data can be lengthy, depending on the complexity of the originating environment, it is possible that data on the 2007 side may be altered during the course of the migration. This option allows for that data to be updated without having to manually delete previously migrated objects.

The next step in the process is to select the collection(s) that will be migrated. It is not required to migrate “all” collections at once as multiple jobs of all types can be configured. The number of jobs will, by default, increase with the complexity of the SCCM 2007 environment as well as with the number of Sites and Security scopes within ConfigMgr 2012.

As you can see above, all of the collections will be displayed as they are laid out in SCCM 2007. Simply select all of the collections that are to be migrated. If the source environment has an immense number of collections, click the search button to display a complete list which can be sorted and narrowed to more effectively locate the desired collection. If migrating associated data with the collection is not required, uncheck the Migrate objects that are associated with the specified collection option at bottom of the wizard page.

As you browse through, it might be possible that the desired collection does appear in either the default list or in the search area. If this occurs, select View Collections that Cannot Migrate. There are 4 scenarios in which a collection will not be available for migration which are outlined below.

• Mixed Query Collections – collections containing users and computers                                                                                                                                                                                                                                                                                                     —This can be eliminated by segregating the mixed collections on the SCCM 2007 side prior to the migration (which is recommended by Microsoft)
• Mixed Collection Hierarchy – collections where the parent and child collections are of different sites
• Multiple Collection Limiting – collection with limited by more than one other collection
• Limited to Blocked Collection – collection that is limited by a collection that cannot be migrated.

Object Selection

Once all of the collections have been selected for this particular migration job, the next page of the wizard will take us through the object selection (assuming it was chosen to do so). This page will only display the objects that are directly linked to the selected collections.

This page is very self-explanatory in that, if there are associated objects to the collections they can be migrated as part of the same job. A few additional notes…

•  In order to migrate the advertisements their associated packages must also be migrated
• Migrated advertisements are not enabled by default (an option to enable is available thought it is not a Best Practice)

Content Ownership

When migrating objects from SCCM 2007 it is necessary to specify the ConfigMgr 2012 content owner. The content owner, for lack of a better description, is the site from which you want the data to originate. If the migration is a single site, this section does not require any additional discussion. However, if there are multiple hierarchies being utilized in 2012, the desired content owner will need to be specified to allow for the proper assignment of data.

Security Scope

The next option is the assignment of a security scope. The security scope is part of the new role based administration model to assign the appropriate rights to the migrated objects based on the defined scopes. As we will not be getting into the detailed overview of Role Based Administration we will just move forward and assume the default scope will be selected.

Collection Limiting

This step of the process is designed to provide you with the ability to limit collections that can in scope once migrated. Let me explain a little further. In ConfigMgr 2012 all collections are global. The means that a collection created from any part of the hierarchy is available to all sites. So, for instance, if you were to migrate a collection from a child primary site that contains “All Windows 7 Systems” from that site when it is brought into the ConfigMgr 2012 environment that collection would now have all of the Windows 7 systems from the entire hierarchy. The migration tool recognizes these issues and allow you to provide the correct collection limiting (limiting is required in 2012).

Site Code Replacement

This step is simple enough. If you have collections that contain queries using the Site Code from the SCCM 2007 environment they will be replaced with the correct site code from the ConfigMgr 2012 environment. This is an automatic process and does not require any configuration.

Reviewing the Migration Job

Now that you have gone through most of the migration job wizard there will be a window providing a review of the configurations and provides some information around the objects that have been chosen to migrate. It also provides information surrounding actions that might need or should be taken prior to the initialization of the migration job.

A new, and useful, feature of the review page is the ability to save the presented information to a file. This obviously will allow the proper tracking of tasks and migration processes for review as well as providing a record of the pre-migration recommendations. I recommend saving all of the files during your migration process as too much information is never a bad thing.

The Settings Page

The settings page of the wizard is where the scheduling of the migration job is configured as well as the defining of actions that will occur while the migration job is running.

The first section of this page is for the scheduling of the migration job. There are three options and they are all self-explanatory…

• Do not run the migration job
• Run the migration job now
• Schedule the migration job

The second section outlines how to handle objects that have been previously migrated. The default selection is Do not migrate updated options which would be my general recommendation. When selecting the collections or objects to migrate the status of those items are provided, (migrated | not migrated), and those that have been migrated should be skipped. If indeed there are items that have been updated since a previous migration job has been run then use the Objects modified after migration job to update them.

Under the additional settings the Transfer the organizational folder structure for objects from Configuration Manager 2007 to the destination site has been pre-selected. If however, you don’t want any of the folder structures to come over during migration, simply uncheck this box. Some organizations may be using this migration as a reason to re-organize data and how items in the ConfigMgr environment are structured so they would chose not to migrate the folder structure. I, on the other hand, find it quite useful.

The last option is one we touched briefly on earlier which enables programs for deployment once migrated. This option needs to be weighed carefully as the ConfigMgr 2012 environment should be set up completely before using it. I make that statement with confidence as in the event an advert and program is enabled on migration and is targeted at a collection that has increased in scope, a number of systems that were not originally intended to run this program may do so. It is not difficult to go through and enable the programs after migration which also provides time to review what systems/users will be targeted.

The last pages of the wizard are ones that configuration manager administrators are very familiar with…summary, progress, completion. This is why I don’t think we all need to review them.

Summary

We have now reached the conclusion of the Migration Made Easy blog series. As always, I sincerely hope that the information that I have included here has been useful, at least in small part, to assist in your upcoming migration.

If you have located this page and have not reviewed Part 1 or 2 click here for a list of my blogs.

It’s a fact of life when working in a large corporate network environment that there will always be the oddball PC that, for whatever reason, cannot be joined to the domain or won’t have the SCCM client installed. These could be lab machines, special purpose kiosk PCs or controllers for manufacturing equipment.

Regardless of why these PCs needed to be orphaned, if they are running Windows, they still need an Antivirus client. This recipe will walk you through the process of putting together the installation media for this task and installing the SCEP client manually on a single PC.

Getting ready

For this recipe you will need to be utilizing an account that has at least the SCEP administrator role assignment attached to it. You will also need an account that has local administrator privileges for the PC on which you’ll be installing the client.

How to do it…

1. Log into your SCCM CAS server and launch your SCCM 2012 management console.
2. Navigate to \Software Library\Overview\Application Management\Packages and right click on the object called Configuration Manager Client Package and select Properties.
3. The Configuration Manager Client Package Properties window should pop up, select that tab titled Data Source and locate the Source Folder field.

4. Make note of the path listed in the Source Folder field then enter this same path into Windows Explorer. Once you’ve done this, you can click Cancel to close the Configuration Manager Client Package Properties window.

5. The contents of the folder should be identical to the screen shot below.

6. The only two files in this directory that we need right now are ep_defaultpolicy.xml and scepinstall.exe.  Copy these to files to a thumb drive or a CD-R.

7. Now login to the PC we’re targeting for a manual SCEP installation and insert the media format you chose in step 6.

8. Open a command prompt with admin privileges and enter the following syntax

In your case, the path for ep_defaultpolicy will be the installation media you’ve selected. Press Enter and the SCEP installer should pop up.

9. Proceed through the wizard, making your selections as you go. Once the wizard has completed, make sure that the SCEP client is able to download its initial set of definitions.

How it works…

The hardest part of this recipe is locating your SCEP client installation media, because the only copy you’ll have is the one that’s been bundled with the SCCM client installation package.

By copying both the SCEP install exe and the policy xml file and then running them manually on a target client, you’ll end up with a SCEP client that starts off with a similar configuration to your normal SCCM-deployed SCEP clients.

Keep in mind that any future changes to this PC’s SCEP policy will need to be done manually. Also, in order to get definition updates, this PC’s SCEP client will either need to be able to reach Microsoft Updates on the internet or a WSUS server in your environment that is enabled to push SCEP definitions.

It goes without saying that any Antivirus related events on this PC will not be reported to the SCCM server. So it will be up to the user of this PC to keep an eye on what’s going on with the system – much like you would manage an AV client on your home computer.

Setting up a CI environment consists of several parts:

1. Dedicated build machine
2. Continuous Integration software
3. Automated and Repeatable Builds
4. Automated Unit and Functional Tests

CSS uses a Continuous Integration process for all of our software development efforts.

A dedicated and standalone build machine serves as a “clean room” environment for building software products.  This machine is a controlled environment, with new software and upgrades taking place only when our development schedule allows.  Build machines are often set up in a virtualized environment, making it easy to expand as well as being “futureproof” if more capacity is needed down the road.

The second part is the CI server itself.   There are several commercial and open-source CI systems, including Jenkins, Microsoft TFS, Atlassian Bamboo, Cruise Control, Cruise Control.NET, and many others.  The CI server is responsible for managing the workflow of your CI process.  It can be triggered to build a software product manually, on a time-basis (Nightly Builds), or on a change-basis by continually monitoring your Revision Control System looking for changes from developers.  CI servers execute your unit tests and analyze the results to help determine the health of a build.  Most CI servers can be configured to archive the build artifacts (binaries, installs, and symbols) after a successful build.

A third component is automated builds.  A fully automated build benefits both the CI process as well as the development team.  Ideally the same automated build system is used by both developers and the CI server.  A developer should only need to install a few pre-requisites onto their machine (such as Visual Studio).  The build script should take care of downloading necessary dependencies (both internal and external) before the source code build begins.

The last part of a CI setup (and a good development practice even without CI) is automated unit and functional tests.  While it’s great to know that a set of changes to the product will compile, it’s even better to know that they didn’t break the functionality.  Even better than that is having this verification take place without any actions by a developer, freeing up developers to remain focused on build product features.

CI Process in Action at CSS

Our continuous integration process kicks in whenever a developer checks in changes to our Revision Control System.  We’re currently using Jenkins as our CI Server.  Jenkins has its roots in the Java realm, but now contains hundreds of plugins to expand its functionality.  So far, it has worked very well for building our .NET-based, as well as native code-based products.   We’re also big fans of the BruceSchneier plug-in for Jenkins.

One of the many bits of Bruce Schneier facts that appear on our build system.

Our existing MSBuild-based build process made it easy to configure Jenkins.  All we had to do was select the Subversion URL for the project, and select our MSBuild script, passing the target name that represents the complete CI build.  We invested a lot of effort into our MSBuild-based build system.  Our goal is to have a single MSBuild template that we re-use for each product, which allows our builds to be consistent and reliable.  Our MSBuild script performs the following tasks:

• Download dependencies
• Compilation of the code for the product
• Unit test projects are built and executed
• Obfuscation  is applied to the build outputs
• Authenticode Signing of the build outputs
• Build the Install
• Authenticode Signing of the Install
• Symbol files posted to our internal symbol server
• Archival  to our internal file server

Once a check-in is detected, the CI server automatically downloads the latest product source.  It initiates a source build, and if successful, continuous on to execute our tests, build the installers, digitally sign the components, and post the build artifacts to our internal file server.  10-15 minutes later, we have a full report about the build, including test results.  Lastly, the CI server notifies us (either through a system tray application or email) whether the build was successful or not.

Continuous Integration process in action.

Conclusions

Setting up a good CI process is no easy task, and requires more than just a nominal amount of work to get it just right.  While there is an up-front cost to this, organizations will undoubtedly see payback from their CI process.  The CI process will immediately discover source code compilation failures and unit test failures, instead of letting them accumulate and hampering productivity across the entire team.  The build history, including unit test execution history, is archived and accessible through the CI server’s portal.  A solid CI process helps keep developers writing code, instead of working on repetitive tasks such as running unit tests or manually building the product.

Links

• Jenkins CI – http://jenkins-ci.org
• Jenkins Plugins – https://wiki.jenkins-ci.org/display/JENKINS/Plugins
• Martin Fowler on Continuous Integration – http://martinfowler.com/articles/continuousIntegration.html
• Wikipedia: Continuous Integration – http://en.wikipedia.org/wiki/Continuous_integration

A custom rules extension is used to determine which management agent is authoritative, and to be sure the user objects being added to the member attribute are from the appropriate domain.

Setting an advanced attribute flow from member to member gives this message:

“Defining a rules extension import attribute flow to a metaverse reference attribute is not allowed.”

But, there is a way around this.

Here’s the set up:

-        Domain A: This is the domain of the parent organization.

-        Domain B: This is the domain of the organization being merged into the parent organization.

-        The security groups all begin life in Domain B. As the merger progresses, their authoritative source will change to Domain A on a group by group basis.

This is indicated when the group is manually moved to the OU called “Domain A Managed” in Domain B.

Here’s the solution. Code for each step will follow this summary:

1. Create a new indexed string multi-valued attribute in the metaverse called memberString.
2. Create a new attribute called SourceCSEntryDN to hold the DN value in Domain B for the security group. (This is used to look up the OU the group belongs to on Domain B when the Domain A MA is synching the group.)
3. Write a function in the rules extension code to determine which OU the group is in.
4. Create an advanced import attribute flow on both management agents to flow members to the new memberString attribute if that MA is authoritative. This value will have the DN of the users who are members of the group.
5. Write an export attribute flow rule on both management agents to flow members from the memberString to the member attribute if that MA is authoritative. Part of this function is to find the connector for the appropriate domain on the mventry for the user CN that is in the memberString attribute.

For steps 4 and 5, the check in step 3 is performed to make sure the right attribute values are being treated as authoritative.

For shared code, a general Utils dll called “UtilsForFIM” was created. Code was also added the import and export attribute flow rules in the respective rules extensions.

For step 2, the attribute flow on the Domain B management agent is:

<dn>, cn ->SourceCSEntryDN

This code puts the entire DN of the user object in the SourceCSEntryDN attribute.

Here’s the code for step 2:

Case “cd.group:<dn>,cn->mv.group:SourceCSEntryDN”

Dim sDNPath As String

Dim dn As ReferenceValue = csentry.DN

sDNPath = (dn.Subcomponents(0, dn.Depth).ToString())

mventry(“SourceCSEntryDN”).Value = sDNPath

 For step 3, the code is a bit different for the Domain A and Domain B management agents. The Domain A management agent relies on the SourceCSEntryDN whereas the Domain B management agent is able to access the dn from the csentry directly.

Both have an attribute flow as follows on the management agent:

<dn>,member -> memberString

This code checks if the dn of the group contains the OU that indicates the group should be managed by Domain A. There are different functions for each domain. Domain A needs to rely on the value that was put into the SourceCSEntryDN attribute, whereas Domain B can read the DN directly from the csentry object.

Here’s the code for step 3 for Domain A:

Public Shared Function IsGroupManagedByDomAByDN(ByVal sDNPath As String) As Boolean

Dim bIsGroupManagedByDomA As Boolean

Dim sDomAManagedGroupOU As String

bIsGroupManagedByDomA = False

sDomAManagedGroupOU = UtilsForFIM.CommonUtils.ReadAppSetting(“FIMConfig/General”, “DomAManagedGroupOU”).ToString()

If (InStr(sDNPath.ToLower(), sDomAManagedGroupOU.ToLower())) < 1 Then

‘Group is still managed by the acquisition domain.

bIsGroupManagedByDomA = False

Else

‘The group is now managed by DomA.

bIsGroupManagedByDomA = True

End If

Return bIsGroupManagedByDomA

End Function

Here’s the code for step 3 for Domain B:

Public Shared Function IsGroupManagedByDomA(ByVal csentry As CSEntry) As Boolean

Dim bIsGroupManagedByDomA As Boolean

Dim dn As ReferenceValue = csentry.DN

Dim sDomAManagedGroupOU As String

bIsGroupManagedByDomA = False

sDomAManagedGroupOU = UtilsForFIM.CommonUtils.ReadAppSetting(“FIMConfig/General”, “DomAManagedGroupOU”).ToString()

Dim sDNPath As String

sDNPath = (dn.Subcomponents(0, dn.Depth).ToString())

If (InStr(sDNPath.ToLower(), sDomAManagedGroupOU.ToLower())) < 1 Then

‘Group is still managed by the acquisition domain.

bIsGroupManagedByDomA = False

Else

‘The group is now managed by DomA.

bIsGroupManagedByDomA = True

End If

Return bIsGroupManagedByDomA

End Function

For both domains, the code is reading the members in the group and writing the dn value of the users into a multivalued attribute called memberString. Here’s the attribute flow for Step 4 and the code:

<dn>,member -> memberString

The code for this transformation for the Domain A management agent is:

Case “cd.group:<dn>,member->mv.group:memberString”

If (mventry(“SourceCSEntryDN”).IsPresent) Then

Dim bIsGroupManagedByDomA As Boolean = UtilsForFIM.CommonUtils.IsGroupManagedByDomAByDN(mventry(“SourceCSEntryDN”).Value)

If (bIsGroupManagedByDomA = True) Then

mventry(“memberString”).Values.Clear()

Dim i As Integer

For i = 0 To (csentry(“member”).Values.Count – 1)

Dim sMember As String = csentry(“member”).Values.Item(i).ToString()

mventry(“memberString”).Values.Add(sMember)

Next

End If

End If

The code for this transformation when the management agent is Domain B is:

Case “cd.group:member->mv.group:memberString”

Dim bIsGroupManagedByDomA As Boolean

bIsGroupManagedByDomA = UtilsForFIM.CommonUtils.IsGroupManagedByDomA(csentry)

If (bIsGroupManagedByDomA = False) Then

mventry(“memberString”).Values.Clear()

Dim i As Integer

For i = 0 To (csentry(“member”).Values.Count – 1)

Dim sMember As String = csentry(“member”).Values.Item(i).ToString()

mventry(“memberString”).Values.Add(sMember)

Next

End If

For step 5, both management agents have the following attribute flow rule:

member <- memberString

Here is the export attribute flow rule for Domain A:

Case “cd.group:member<-mv.group:memberString”

Dim bIsGroupManagedByDomA As Boolean

If (mventry(“SourceCSEntryDN”).IsPresent) Then

bIsGroupManagedByDomA = UtilsForFIM.CommonUtils.IsGroupManagedByDomAByDN(mventry(“SourceCSEntryDN”).Value)

If (bIsGroupManagedByDomA = False) Then

csentry(“member”).Values.Clear()

UtilsForFIM.CommonUtils.memberStringToMembers(mventry, csentry, csentry.MA.Name)

End If

Else

‘Source csentry dn is missing

End If

And for Domain B:

Case “cd.group:member<-mv.group:memberString”

Dim bIsGroupManagedByDomA As Boolean

bIsGroupManagedByDomA = UtilsForFIM.CommonUtils.IsGroupManagedByDomA(csentry)

If (bIsGroupManagedByDomA = True) Then

csentry(“member”).Values.Clear()

UtilsForFIM.CommonUtils.memberStringToMembers(mventry, csentry, csentry.MA.Name)

End If

Here’s the memberStringToMembers function that translates the membership from the string value to the appropriate csentry for the domain the group is being exported to. Note that this is taking the connector on the mventry of the member for the MA that is processing the current run so that we have the user object in the appropriate domain.

Public Shared Sub memberStringToMembers(ByVal mventry As MVEntry, ByVal csentry As CSEntry, ByVal sMAName As String)

Dim i As Integer

For i = 0 To (mventry(“memberString”).Values.Count – 1)

Dim sMember As String = mventry(“memberString”).Values.Item(i).ToString()

‘Need to find the mventry for this connector and then determine the DomA csentry.

Dim mvEntryMember() As MVEntry

Dim arrMVEntryCN As Array

Dim sMemberCN As String

arrMVEntryCN = sMember.Split(“,”)

sMemberCN = arrMVEntryCN(0).Replace(“CN=”, “”).Replace(“cn=”, “”)

mvEntryMember = Utils.FindMVEntries(“cn”, sMemberCN, 1)

If (mvEntryMember.Length > 0) Then

Dim ManagementAgent As ConnectedMA

Dim Connectors As Integer

ManagementAgent = mvEntryMember(0).ConnectedMAs(sMAName)

Connectors = ManagementAgent.Connectors.Count

If (Connectors > 0) Then

Dim csentryFound As CSEntry

csentryFound = ManagementAgent.Connectors.ByIndex(0)

csentry(“member”).Values.Add(mvEntryMember(0).ConnectedMAs.Item(sMAName).Connectors.ByIndex(0).DN.ToString().ToLower())

End If

End If

Next

End Sub

What this video attempts to show you, is what that migration process would look like when it’s done in conjunction with a Windows 7 OS deployment.

Watch my full Migrate to Forefront Endpoint Protection during a Win7 Migration with SCCM here.

It’s been a long road getting to here I’m sure. You’ve got a perfectly tuned SCCM 2007 infrastructure, you’ve upgraded to R2, and that installation of service pack 2 is now nothing but a quaint memory. Now you’ve decided to take things to the next level by virtualizing some of your applications. The App-V installation that was on the Microsoft Desktop Optimization Pack was a breeze, and then your greatest dreams are realized! App-V integrates with SCCM! Now you can push virtualized applications and stream them from your distribution points! Offline availability? Not a problem here friends. Life is good.

Ok, so I’m being a little dramatic. The truth is that application virtualization is seeping its way into many organizations in an effort to cut down on individual PC overhead and maintain more control over individual apps for a variety of reasons. Perhaps it is to maintain different versions of the same program, or even to centralize control of an app for licensing reasons. App-V can help and its integration into SCCM is simple.

Let’s start with the basics. Before beginning I would recommend that you are on SCCM R2 SP2 at least. Application virtualization tools were introduced into SCCM at R2 and SP2 is required for the latest iteration of App-V (4.6 at this writing). On the App-V side, only the App-V client needs to be on the PC running the virtualized application and an installation of the App-V Virtualization Sequencer is required in order to sequence apps.

Now that the prerequisites are out of the way, let’s jump right into the breach by opening up the Configuration manager console. Navigate to Site Database/Site Management/{Primary Site Name}/Client Agents. Double click on the Advertised Programs Client Agent. The third check box under Client Settings is “Allow virtual application package advertisement.” Put a check in that box and Click OK.

The next step is to go to every Distribution Point that will be streaming or delivering virtualized applications and enable BITS, and Application Streaming. Navigate to Site Database/Site Management/{Site}/Site Systems/{Site Server Containing the Distribution Point Role}. On the right side double click on the ConfigMgr Distribution Point role to bring up its properties. Ensure there is a check in the box under communication settings to “Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS (required for device clients and Internet-based clients).”

Now in that same dialog box click on the Virtual Applications tab. There is a box for “Enable virtual application streaming.”  Select it and click OK.

As an important note there are two ways of delivering a virtual application. The first way is to have it stream directly from a Distribution Point. The second way, for slower connections for offline use, is to use local delivery. If using only local delivery and NO streaming, then you don’t have to select this check box, however, if you plan on using either method then this box MUST be checked.

Congratulations, you’ve done it. The moment you clicked to enable virtual advertisements in the Advertised Programs Client Agent box, SCCM started to take control of the App-V client on all SCCM clients. It is important to note here that an unfortunate side effect of that is the Configuration Manager Advanced clients will remove ALL previously deployed virtual application packages (published through an App-V Full Infrastructure or standalone MSI). Keep this in mind. Now you have the ability to create New Virtual Application packages under software distribution and advertise them.  You can stream apps and update them from a central point.

Now you’ve gone to the next level.

A good read on this topic is the App-V whitepaper section of Technet located at http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx

Hi again everyone!  My name is Jim Jankowski.  I’m the Group Manager for Certified Security Solutions’ Secure Infrastructure Management team.  Last month we kicked off our ‘Windows 7 Accelerate with System Center’ marketing campaign.  My first topic in the marketing campaign was ‘Accelerating Windows XP to Windows 7 Migration using System Center Configuration Manager 2007’ which includes a 5-part how-to video (available here) as well as a corresponding blog posting (available here).

My topic this month is ‘Preparing for User File and Settings Migration using System Center Configuration Manager 2007’ which is a 2-part how-to video (available Part 1 & Part 2) and this blog which provides additional relevant information not included in this month’s video.

[Back]

800 Days Until Windows XP End of Support

One of my favorite blogs is the ‘Springboard Series Blog’ by Stephen Rose at Microsoft.  This month Stephen provides an update on the end of support for Windows XP which is now less than 800 days (23 months) away.  As Stephen points out, when you consider it typically takes 18-24 to migrate from Windows XP to Windows 7, time is running out for customers who still have not started their Windows 7 migration.   Fortunately that is where CSS can help and is the premise for our ‘Windows 7 Accelerate with System Center’ marketing campaign.   Stephen’s blog (available here) is packed full of information and definitely worth the time to review.

[Back]

 USMT Builder

If you are like me, I sometimes feel like a fish out of water when trying to edit the USMT XML configuration files.   Enter USMT Builder (available here) by Simon Jarvis.

USMT XML Builder Features:

• Speed – fast accurate editing of USMT command line templates/migration scripts.
• Sophisticated – support for all major USMT elements and internal functions.
• Syntax checking for XML USMT elements.
• USMT GUI based object access to backup/migration of files and settings.
• Complex object rules such as filter, detection, merging of data/settings made easy.
• Supports USMT version 3.01 and 4 functions, elements and command line options.
• Single deployable executable package for backup and restore for remote migrations.
• Supports existing manually created templates/migration scripts.

Figure 1 – USMT Builder – MigConfig.xml

[Back]

Manual restore of user state from SCCM

One of the areas I did not talk about in my ‘Preparing for User File and Settings Migration using System Center Configuration Manager 2007’ how-to video this month (available Part 1 & Part 2 ) is the ability to manually restore user files and settings to a system that successfully performed the user state capture but for some reason is not able to perform the user state restore successfully.  This can be done quite easily by obtaining the recovery information from the ConfigMgr console and using the Easy Transfer tool to perform the user state restore on any Windows 7 system.

First, obtain the user state store location and encryption recovery key from by right clicking on the system you need to restore the data from in ‘Computer Association’ node in the ConfigMgr console and selecting ‘View Recovery Information…’ as seen in Figure 1 below.  Refer to Figure’s 2 through 7 for the remaining steps.

Figure 2 – Right click and select ‘View Recovery Information’

Figure 3 – Copy ‘User state store location’ UNC path and ‘User state recovery key’

Figure 4 – Open the ‘User state store location’ UNC path on the Windows 7 system and to the USMT folder

Figure 5 – Double click on the USMT.mig file

Figure 6 – Paste in the ‘User state recovery key’ when prompted then click next

Figure 7 – Select the required default or advanced options and click the Transfer button

[Back]

Additional Information and Resources

Certified Security Solutions

• Windows 7 Accelerate with System Center website ->http://www.css-security.com/countdown
• Customer Demo Environment Dashboard
  • Internet Explorer ->status.joltsecurity.com ¹
  • Windows Phone and SmartPhones -> mobile.joiltsecurity.com ²
  • Secure RDS/VDI Access ->https://www.joltsecurity.com/rdweb ³
  • Secure Infrastructure Management
  • Contact Sales -> sales@css-security.com

¹ Best viewed with Microsoft Silverlight

² Best viewed with a mobile browser that supports HTML5

³ Requires username and password top access (click here to request access)

Microsoft

• Microsoft System Center Website
• Windows 7 Deployment (Springboard) website
• Microsoft Desktop Optimization Pack (MDOP)
• Microsoft Deployment Toolkit (MDT)
• Microsoft Application Compatibility Toolkit
• Microsoft Assessment and Planning Toolkit
• Windows 7 Application Compatibility List for IT Professionals

[Back]

There are number of organizations out there who are discussing or currently testing implementations of Microsoft’s BitLocker Administration and Monitoring (MBAM).  There are a number of things that the recently released enterprise management of BitLocker does well, such as compliance reporting, single use key recovery, and trusted platform module (TPM) management.  However, the deployment of MBAM does cause some issues for many and I will be discussing some topics in this blog that will hopefully provide some assistance to those currently testing or deploying.

Microsoft’s Desktop Optimization Pack (MDOP) online help webpage provides some key information to assist in the deployment; however, there are some missing pieces.  Hopefully you will find some of this information useful.

Network Encryption Certificates

For some you who, like me, are not certificate gurus but know enough to grasp the general concept of requirements, you may notice that when looking over the MBAM information on the MDOP Online Help pages, no certificate requirements are listed.  So in order to ease your process of installation I will give you some information that has worked for me while delivering MBAM engagements.

Basic Requirements

The requirements for the certificates relating to MBAM are straightforward and typically do not require significant modifications to an organization’s PKI. The Extended Key Usage (EKU) requirements of the certificates are as follows:

Client Authentication       (1.3.6.1.5.5.7.3.2)

Server Authentication      (1.3.6.1.5.5.7.3.1)

These two EKU’s are typically found together in the default Computer certificate template of an Enterprise CA, but can easily be added to any computer template you wish.

Two certificates should be issued for use with MBAM.  The first certificate is used to encrypt the communication between the SQL Server hosting the databases and the Administration and Monitoring Server.  The second certificate is used to encrypt the communication between the Administration and Monitoring server and the MBAM client agent.

Please note:  In order for these two certificates to be useful, it is required that they chain up to a CA that that your computer trusts. If the Windows7 or Server2008 systems do not trust the CA that issued these certificates, you may need to add that CA, or its root CA, to the system’s Trusted Publishers Certificate Store.

Certificates not showing up…?

Some of you may have experienced nothing but blank space in the certificate pull down box when performing the installation of the MBAM components when you are at the “select the certificate to encrypt network communication page.”  You may have your certificates successfully created, but in order for them to be available during installation they have to be manually installed to the personal certificate store of the local computer.

If you receive an error that makes reference to the certificate not meeting the necessary requirements, make sure that you have performed the actions listed in the previously mentioned note.

Policy Templates

The last component in the MBAM component installation list is the Policy Templates.  While this item is listed as a component that gets installed, it in fact does not perform system changes of any kind.  When checked, this step merely copies the ADMX and ADML files to the local policy definitions folder of the server on which the feature was “installed.”  The files in question along with their respective file paths are listed below:

If your organization has a specific server or servers that are used to manage group policy then these files need to be copied to the local policy definitions folders on each server.  However, if you have a central policy store within SYSVOL for policy management, copy all of the files to the appropriate locations to enable management of the MBAM policies.

If everything is copied to the correct locations when editing a GPO you should see the following:

MBAM Client Registry Information

There are several registry keys associated with the MBAM client that you can manipulate to force the client into action.  These items are categorized below to be used as a reference guide.

Hardware Compatibility Checking Policy

When using Hardware Compatibility Checking with MBAM systems, validate their hardware profile against the policies within MBAM.  This allows for control of encryption on system that may or may not meet your organization’s hardware standards for encryption.  The downside to this is that when a system checks in and the hardware profile is listed as unknown, the system then waits 24 hours before checking in again.  The registry keys listed here are responsible for these actions.

The client can be forced to check in prior to the 24 hour mark by deleting the above mentioned registry keys and performing a restart of the MBAM client.

Startup Delay

By default the MBAM client has a 90 minute random delay, upon startup, before communicating to the Administration and Monitoring server.  This was designed to reduce the load on the MBAM server during the initial deployment of the MBAM client.  However, this delay can be circumvented by adding the following registry key.

If this setting is to be temporary it will be necessary to remove the registry key after the fact as none of the MBAM Group Policy settings will overwrite this key.

User Prompting

When configuring the MBAM services via Group Policy there are two policy timers that are configured.

Client Checking Status Frequency (Default: 90 Min)
Status Reporting Frequency (Default: 720 Min)

These timers have corresponding registry settings that can be manually changed to initiate their checks immediately when the MBAM client is restarted.  This is generally performed to more quickly initiate the user prompt for starting the encryption process as well as forcing the status reporting to update.  These keys and the values to which they should be changed to initiate their checks are listed below.

Encryption during Operating System Deployment

The following registry keys are used to configure MBAM to initiate encryption during the deployment of the Windows 7 Operating System.  This information can be referenced from the original source.

Additional information regarding the encryption via MBAM during Operating System Deployment can be found here:   http://onlinehelp.microsoft.com/en-us/mdop/hh285657.aspx

I hope that some or all of this information is useful in either your testing or deployment of Microsoft BitLocker Administration and Monitoring.

Please be sure to check out the Windows 7 Accelerate with System Center website at www.css-security.com/countdown for installation and tutorial videos on MBAM.  You can also find additional resources, videos and datasheets on migrating from Windows XP and Deploying Windows 7.

Certified Security Solutions sent a team to the 2012 RSA Security Conference in San Francisco where one of the underlying themes was mobile security.  Located in the Microsoft Pavilion, team CSS boasted a ‘Got PKI?’ theme centered around PKI best practices and the power of digital certificates on mobile devices. Booth conversations included PKI as a service in addition to leveraging CSS’ own software products (CRT & mCMS) for digital certificate management and enrollment in a Microsoft PKI.  Visitors to the booth were genuinely excited to see a mobile security solution from a company that “gets” PKI.  CSS’ CTO, Ted Shorter, and Director of Business Development, Uri Lichtenfeld, presented a theater session titled ‘Do’s and Don’ts of PKI and Certificate Management for Mobile Devices.’ Check out the photos below:

To learn more, please click the following links or contact us:

• PKI services
• Certificate Reporting Tool (CRT) 
• Mobile Certificate Management System (mCMS)

• Windows 7 Accelerate with System Center marketing campaign
• Why you shouldn’t wait for Windows 8 (hey, that rhymes!)
• 04/08/2014, is it Y2Kv2?
• ConfigMgr Client Health Status Reporting and Remediation
• ConfigMgr Operating System Deployment Collection Variables
• Additional Information and Resources

Hi Everyone!  My name is Jim Jankowski.  I’m the Group Manager for Certified Security Solutions Secure Infrastructure Management team.  This month we are kicking off our ‘Windows 7 Accelerate with System Center’ marketing campaign.  Our first topic in this marketing campaign is ‘Accelerating Windows XP to Windows 7 Migration using System Center Configuration Manager 2007’ which includes a 5-part how-to video (available here) as well as this corresponding blog posting which provides additional relevant information not included in the video.

Why you shouldn’t wait for Windows 8

To start with, you might be asking yourself, why should I deploy Windows 7 when Microsoft has already announced the release of Windows 8 and just announced the availability of Windows 8 Consumer Preview?   The answer depends on how far along you are with your Windows 7 deployment or deployment planning since a typical Windows deployment takes 18 to 24 months.  The other consideration is how soon after Windows 8 is released, will software vendors address any business critical application compatibility issues with Windows 8.  Since Windows 8 will have a brand spankin’ new interface and be designed for touch as well as keyboard, pen, and mouse, chances are it will take software vendors some time to address application compatibility issues.

Since the end of support, or what we like to call WinXPDOA, is 25 months, 5 days, 12 hours, 38 minutes, and 40 seconds away (at the time I’m authoring this blog) and the fact that Windows 7 has been out for quite some time now, is extremely stable, reliable, and secure and can run on most systems that run Windows XP today we feel are the reasons why you should deploy Windows 7 now.  And, if your automated Windows operating system deployment process is designed properly now, dropping in Windows 8 for deployment to more modern based touch devices when the time comes should require minimal effort.

BACK to top

April 8, 2014, is it Y2Kv2?

So why do we think it might be Y2Kv2?  In retrospect, the biggest problem customers had with Y2K wasn’t the doom and gloom that was predicted, it was the lack of available resources to help with Y2K remediation.  The result is what usually happens when demand greatly outweighs supply, which was a significant increase in the costs of resources as 01/01/2000 approached.   All that being said, now is the time to start your Windows 7 migration.

BACK to top

ConfigMgr Client Health Status Reporting and Remediation

One of the areas I briefly talk about in my ‘Accelerating Windows XP to Windows 7 Migration using System Center Configuration Manager 2007’ how-to video (available here) is the ‘ConfigMgr Client Health Status Reporting and Remediation’ capabilities included with the R2 release for ConfigMgr 2007.

Next to BIOS upgrades, the health of your ConfigMgr clients is probably the most import thing to address prior migrating your Windows XP systems to Windows 7 using ConfigMgr.  Simply put, if a ConfigMgr client is not healthy, the migration process will fail and your Windows 7 deployment project will be in jeopardy of crashing and burning.

By deploying the Client Status Reporting included with the R2 release for ConfigMgr 2007, you will be able to leverage a set of tools and reports to more easily check the status of the ConfigMgr client across your organization and identify the systems that need remediation.

“Client status reporting in Configuration Manager 2007 R2 provides up-to-date information on the manageability of clients in a Configuration Manager 2007 hierarchy. This information can be used by the site administrator to identify individual client problems and to maintain a more accurate site database. It can also help to increase deployment success rates.”

As for remediation, based on our experience with customers, 90% of all ConfigMgr client health issues can be addressed by uninstalling and re-installing the ConfigMgr client.

Included below is a list of ‘Client Status Reports’ included with ConfigMgr 2007 R2 as well as an example ‘Client Status Summary Report’ for your reference…

Figure 1 – Client Status Reports

Figure 2 – Client Status Summary Report

BACK to top

ConfigMgr Operating System Deployment Collection Variables

Another area I talk about in my ‘Accelerating Windows XP to Windows 7 Migration using System Center Configuration Manager 2007’ how-to video (available here) is using task sequence variables and if/then logic to create a single Windows 7 task sequence that can do the following…

Perform an automated full installation of the 32-bit or 64-bit versions of Windows 7.  A full installation would include the operating systems, core applications, departmental applications, security tools and related corporate configuration settings, and the backup and restore of user files and settings.

• Perform an automated clean installation of the 32-bit or 64-bit versions of Windows 7 for lab, development, testing, training, or application packaging systems that do not need a full installation.
• Perform an automated image build installation on a reference computer to create the standard 32-bit and 64-bit Windows 7 images used to deploy windows 7 during the full and clean installations which will typically eliminate the errors that occur when manually building an image.

I cover this in detail in my video, but what I don’t cover is how I set the corresponding task sequence variables.  I do this using ‘Collection Variables’ which are set at the collection level (as seen in Figure 3 and Figure 4 below).  Note that there are other way to do this such as prompting for the corresponding information from within Windows PE using the new Microsoft Deployment Toolkit UDI (User Driven Interface) feature or from an HTA application like I showed in my video password protect the Windows 7 deployment task sequence, but for many customers, using ‘Collection Variables’ is more than adequate.

The task sequence variables I prompt in my video for are used to set the computer name and computer description as well as OSBuildType (Full, Clean, or Build), and OSType (x86 for 32-bit or x64 for 64-bit version of Windows 7).  Refer to Figures 5, 6, and 7 below to see how the ConfigMgr task sequence will prompt for this information when Windows PE boots and starts the Windows 7 installation task sequence for a new system.

Figure 3 – Modify Collection Settings

Figure 4 – Collection Variables

Figure 5 – Windows 7 Installation Task Sequence for a New System

Figure 6 – Task Sequence Variables Prompt

Figure 7 – Task Sequence Variable Values

 BACK to top

Additional Information and Resources

Certified Security Solutions

• Windows 7 Accelerate with System Center website - http://www.css-security.com/countdown
• Customer Demo Environment Dashboard
  • Internet Explorer -  status.joltsecurity.com ¹
  • Windows Phone and SmartPhones - mobile.joiltsecurity.com ²
  • Secure RDS/VDI Access -https://www.joltsecurity.com/rdweb ³
  • Secure Infrastructure Management
  • Contact Sales – sales@css-security.com

¹ Best viewed with Microsoft Silverlight

² Best viewed with a mobile browser that supports HTML5

³ Requires username and password top access (click here to request access)

Microsoft

• Microsoft System Center Website
• Windows 7 Deployment (Springboard) website
• Microsoft Desktop Optimization Pack (MDOP)
• Microsoft Deployment Toolkit (MDT)
• Microsoft Application Compatibility Toolkit
• Microsoft Assessment and Planning Toolkit
• Windows 7 Application Compatibility List for IT Professionals

BACK to top