Stuart James at myITforum.com

ConfigMgr Schema Extensions Not Applied When Upgrading

I've seen this a few times now so worth a post.  If you already have the SMS 2003 SP2 schema extensions in place and then use the ConfigMgr_ad_schema.ldf file to update the schema you may find that certain attributes are missed.  The missing ones will be:

• mSSMSCapabilities
• mSSMSVersion
• mSSMSSourceForest

These are all attributes within the MS-SMS-Management-Point class.  This happens because the DNSHostName attribute already exists if you have extended the schema for SMS 2003 SP2.  This causes the whole section of the LDF to be skipped.

You will see entries like below in the LDIF log file:

41: CN=MS-SMS-Management-Point,CN=Schema,CN=Configuration,dc=REMOVED,dc=REMOVED
Entry DN: CN=MS-SMS-Management-Point,CN=Schema,CN=Configuration,dc=REMOVED,dc=REMOVED
changetype: modify
Attribute 0) mayContain:mSSMSCapabilities mSSMSVersion mSSMSSourceForest dNSHostName

Attribute or value exists, entry skipped.

And if you are publishing to AD you'll find that along with the new attributes not being populated, the DNSHostName attribute is not updated either.  This is because the site needs to be able to verify that the ConfigMgr version of the schema is in place before it can update the DNSHostName attribute (see http://technet.microsoft.com/en-us/library/bb694066.aspx). You will see entries like the following in sitecomp.log:

Publishing SERVERNAME(SERVERNAMEFQDN) as a Management Point into Active Directory
SMS-MP-SITECODE-SERVERNAME could not be updated, error code = 8212.
SMS-MP-SITECODE-SERVERNAME successfully updated, using the SMSv1 AD Schema.

Error 8212 means "The requested operation did not satisfy one or more constraints associated with the class of the object"

The workaround in this case is either to create a custom LDF file that just applies the three new attributes named above (and apply this after you've applied ConfigMgr_ad_schema.ldf) or to use the ExtADSch.exe tool.  The tool does not suffer the same problem and should apply all the attributes successfully. The custom LDF file would look something like:

#-------------------------------------------------------
# Add whatever comments you want here
#-------------------------------------------------------

dn: CN=MS-SMS-Management-Point,CN=Schema,CN=Configuration,DC=x
changetype: modify
add: mayContain
mayContain: mSSMSCapabilities
mayContain: mSSMSVersion
mayContain: mSSMSSourceForest
-

dn:
changetype: modify
replace: schemaupdatenow
schemaupdatenow: 1
-

Mobile Device Security Settings: Exchange Mailbox Policies versus SCCM/ConfigMgr 2007

This post focuses on Exchange 2007 and ConfigMgr, although is mostly relevant to Exchange 2003 as well.

Exchange 2007 introduces ActiveSync Mailbox Policies.  These can be used to enforce and configure various settings on Mobile devices. Settings such as requiring a password, the password length, the password complexity, enabling the download of attachments, access to UNC and Windows SharePoint Server Shares can now all be configured using Mailbox Policies for ActiveSync.

Most of these settings (and also many more I hasten to add) can also be configured using the device management features in SCCM/ConfigMgr.  I've created a table below to map the equivalent settings between the two.  The left hand column shows the Exchange setting.  The right hand column shows where to find the equivalent in SCCM.  In some cases within SCCM they are configured in different "configuration types" depending on the platform.  In some cases there is no equivalent in SCCM.

Now, the question facing many will be "which should I use, Exchange or SCCM?".  The answer I suspect is the ubiquitous "It depends".  I expect many will enforce through both for the following reasons:

• Not all devices connect to Exchange, but you might still want to enforce these settings.  You therefore want to enforce the settings using SCCM.
• It is likely that not all devices trying to connect to Exchange will be managed by SCCM (e.g. they may not have the client installed yet).  You will therefore want to enforce the settings using Exchange.

Therefore, I think the solution is to enforce settings through both solutions, meaning that the Exchange and SCCM teams will need to be communicating with each other when planning this.  However, what if they're not and the Exchange team configure a setting different to the SCCM team?  In that case, it will be a case of whoever wrote the value last will win, so expect the setting to be in a constant state of change on those devices.

Software Update Management: Managing SUM objects

Following on from my post on the new objects in Software Update Management I thought I'd jot something down around how to manage the two main objects: Deployment Packages and Deployments.

This is all subject to change as it's still a new feature.  No doubt best practices will change but at least this is a starting point and I'll come back to it in the future to keep it up to date.

Deployment Packages

Clients can install targeted updates from any deployment package available.  This gives you a lot of flexibility in this feature.

At its simplest, you could just create a single package that contains all updates that you want to install and distribute this to all of your distribution points.  If you have lots of storage on your DPs then this is an easy option that removes a lot of admin effort.  However, you may be wasting a lot of storage and network usage when doing this.  Some ways you may want to cut this down are:

• Create language specific packages and distribute this to the applicable regions.
• If you know a certain site only manages servers then create a package specifically for server updates, similarly if the site only manages PCs.
• If you know that a certain application is only used in a certain region then create a package containing updates for that application and only distribute to the applicable region's DPs

With any of the above you do need to consider roaming clients.  For example, if a computer from one language region roams to another site and you still want it to receive updates when roaming you'll need to accept that these will come across the WAN from the assigned site DPs rather than locally.

So all this probably leads most people to think "I'll just stick everything in one package, that's much easier".  A few words of warning:

• That package is going to get very large after time.  If that package somehow becomes corrupted on one of your DPs and you need to refresh it then that is a lot of data to have to send to the DP again.
• At some point you will want to reclaim some storage and clear out a lot of updates that are no longer required.  If you only have one large package then this will  be a cumbersome task.

For the above reasons I would avoid a single large package and instead go with something like a yearly package.   Another option is to go with platform based packages, that way when you no longer have any Windows XP clients (you're all upgrading to Vista right?) you can get rid of the Windows XP package and get some of your storage back.

Deployments

My initial instinct for this was to try and do things in the same way as most of us used to with SMS 2003 i.e. one large "sustainer" package and then a monthly smaller package (if anyone hasn't already heard of this approach with SMS 2003 then let me know and I'll post something, but most are probably familiar with it).

You would therefore have two deployment objects:

• A "sustainer deployment": Contains all updates other than those released on the most recent month. Deadline is set to some time in the past so that any out of date clients install these updates as soon as possible to ensure that all computers meet a certain baseline.
• A "monthly deployment":  Contains updates released in the most recent month. Deadline is set according to the highest priority update within the deployment. This ensures that users have a certain period of time each month to install updates before the deadline is reached. If an update deemed critical is included in the deployment then the deadline will be shorter than if all updates are a low priority.

This would mean that each month (when new updates are released) you move the updates in the current "monthly" to the "sustainer" and add the new updates to the "monthly", and update the deadline on the "monthly" accordingly.

However, whilst this represents an easy way to do things, there are some drawbacks. The main one is that information on the updates included in a given deployment is stored in a single policy per deployment.  After time the "sustainer" could have hundreds of updates in and this policy could grow to several MBs.  Each time you move updates into the sustainer the policy gets updated and clients need to download it again.  This is rather wasteful and depending on your network and design could have some nasty network impact.  It also gets cumbersome for the client to process such a large policy.

Therefore, with this in mind I believe a better approach is to create a new deployment each month.  That keeps the policy small and means that once a client has downloaded the policy for that month, it never needs to again.  It also makes it easier to clear things out at a later date if you no longer need deployment objects that are years old.

Of course, you may also need to create other deployments for specific purposes or exceptions but if I try and list what all of those might be I'll be here all day.  You'll figure these out as you start thinking about how you're going to use the feature.

Final Thought

I haven't gone into them here, but remember, Update Lists are your friend(s).  Take a look at the online guidance: http://technet.microsoft.com/en-us/library/bb693591.aspx. 

Software Update Point Client Install: Careful with those GPO settings

A bit of a rambling one, but bear with me...

Software Update Point client installation is a new client deployment option for ConfigMgr. At a very high level, it involves publishing the client as a required update in WSUS and then pointing your "clients to be" at the correct WSUS server from which they can install the client.  How to do this is all covered in the online guidance here, so I won't repeat: How to Install Configuration Manager Clients Using Software Update Point Based Installation

You'll see that the article discusses the option of using GPO to tell clients which WSUS server to get the client from. This effectively stamps in the registry where the Windows Update Agent should go to get updates.

However, the same registry entry that is stamped by GPO is also the entry that once installed, the ConfigMgr client will want to configure to point to the SUP for its assigned site.  This is where the problems can arise.  If the GPO says one thing and the SCCM client wants to assign something else then each will be conflicting.

In many cases your OUs/AD sites etc will be organised in a way that means you can get away with setting the same server through GPO that SCCM would then assign later.  Let's say for example that you had one SCCM primary site per domain, one of which we'll call DOMAINX.  You could therefore set a GPO on DOMAINX that points to your primary site SUP and then once the client is installed, SCCM will configure the same SUP, as all your clients in DOMAINX will be assigned to that one site.  All well and good.

Problems can arise if your SCCM infrastructure is organised differently to anything you can mirror in AD to apply the GPOs.  Let's say for example you have a domain with two SCCM primary sites in.  Each of these manages a set of subnets and you have no geographical data in your OU structure.  We're also assuming here that the AD sites are not suitable to be used as SCCM sites (which is not always the case).  You don't have a way to configure a GPO setting that is guaranteed to point to the same server that the client will want to point to once assigned.

There are a few troubleshooting steps related to this on the Microsoft web site that cover some of the issues you may see: http://technet.microsoft.com/en-us/library/bb735866.aspx.  I highly recommend you read through it if you're considering this deployment option.

In summary though, before diving into using this client deployment method have a think about your AD structure versus your ConfigMgr structure to see if this method still makes sense.

There are also a few workarounds.  The real issue here is caused because GPO settings will override the local policy settings that ConfigMgr configures.  The solution if you don't have a nice matching domain environment is therefore to set the value without using GPO.  A simple way to do this is via a script or a local policy.  For example, you could send a script out that says "if this value isn't set yet then set it to SERVER_XYZ".  You could still send the script out via GPO to ensure they go to a fairly local WSUS server for the client installation files.  However, once the client in installed it will overwrite that value with the SUP for the assigned site.  This will then remain in place as you don't have a GPO set to configure it to something else...

Technet Chat Transcripts

If you haven't seen them then these are a really good resource.  The whole list can be found here:

http://www.microsoft.com/technet/community/chats/trans/default.mspx#e3pae

There are a bunch of useful ConfigMgr topics up there including:

SCCM 2007 IBCM & Native Mode (July 24, 2007)

SCCM 2007 Desired Configuration Management (July 19, 2007)

Software Updates Management with System Center Configuration Manager 2007 (July 12, 2007)

Operating System Deployment with System Center Configuration Manager 2007 (July 10, 2007)

Deploying System Center Configuration Manager 2007 (June 29, 2007)

Enjoy!..

Oops, feeds are fixed now

New Objects in Software Update Management

The Software Update Management (SUM) feature in System Center Configuration Manager 2007 no longer uses the software distribution components (packages, programs, and advertisements) to distribute software updates to client computers, but instead uses deployment packages and deployments. There are also a few other objects to help make administration of this feature easier which are discussed at the end of the article.

Deployment Packages
Deployment packages host the software update source files. Deployment package objects are replicated to child sites as read-only objects.

Deployment packages contain software update source files and are created either by running the Download Updates Wizard or Deploy Software Updates Wizard. Both methods download the software update to a network shared folder, compress it into a package file, and extract and copy the software update files to each distribution point defined in the deployment package.

There is no hard link between a deployment and deployment package. Clients install software updates in a deployment by using any distribution point that has the software updates available, regardless of the deployment package. Even if a deployment package is deleted for an active deployment, clients are still able to install the software updates in the deployment as long as each update has been defined in at least one other deployment package and available on a distribution point accessible from the client.

Deployments
Deployments are used to deploy software updates to clients in the target collection. Deployment objects are replicated to child sites as read-only objects.

When client computers receive a mandatory deployment, they connect to a distribution point, download the software updates in the deployment to their local cache, and initiate the installation of mandatory deployments at the configured deadline. Deployments that are optional must be initiated by the user, and at that time the software updates are downloaded to the local cache and installed.

When clients receive a new deployment, they will use the software update source files from any distribution point that has them, even from a package and distribution point that were not configured in the deployment package defined for the deployment if necessary.

In Configuration Manager 2007, software updates are always downloaded to the local cache and then installed. There is no longer an option to install the software updates directly from a distribution point as there was in SMS 2003 using ITMU. The new selective download feature plays an important part here.

Selective Download
Selective download is a new feature in Configuration Manager 2007. Client computers identify which targeted software updates are required and only retrieve the files appropriate for installation from the package contents that might contain both applicable and non-applicable software updates. This allows administrators to have multiple software updates in a single deployment package and use the package in deployments that target clients which only need a subset of the package contents.

When a client receives a software update deployment instruction with an assigned deadline, clients download the applicable software update files immediately to the local cache. The installation for software updates with an assigned deadline occurs either when the deadline is reached or when the installation is manually initiated prior to deadline. Optional software updates are downloaded to the local cache only after installation is manually initiated.

There is no longer an option to run the software update installation from the network for Configuration Manager 2007 client computers. SMS 2003 clients continue to have this option.

Deployment Deadline
Deployments can be configured with a deadline. Setting a deadline makes the deployment mandatory and enforces the software update installation on client computers by the configured date and time. If the deadline is reached and the software update deployment has not yet run on the client computer, the installation starts automatically whether or not a user is logged on. A system restart may be enforced if it is necessary for the software update installation to complete.

Important Difference
In SMS 2003, deadlines were set to occur x days after either the client received the policy to install a software update, or after a software update was authorised. This meant that individual updates within a given package could have different deadlines. Deployment deadlines in Configuration Manager 2007 are now configured for an explicit date and time for a given deployment, and can no longer be individual to each update within a deployment. SMS 2003 clients that are still in the Configuration Manager hierarchy will also use the configured deadline date and time for deployments targeted to them.

Client Settings
When a client receives a software update deployment policy with a configured deadline, the required software updates are downloaded immediately and stored in the local cache. The client computer will run software update installation from the local cache when the deadline is reached or the installation is initiated manually from the Available Software Updates dialog box.
When software updates that have a configured deadline become available, a display notification is presented in the notification area that informs users of the pending deadline. Display notifications are presented on a periodic basis until all pending mandatory software update installations have completed. By default, they are displayed every 3 hours for deadlines more than 24 hours away, every hour for deadlines less than 24 hours away, and every 15 minutes for deadlines that are less than 1 hour away.

Other Objects
In addition to the two key objects above (deployment packages and deployments) there are a number of other objects that help simplify update management.

Deployment Templates
Deployment templates store many of the software update deployment properties and are used when creating software update deployments to ensure consistency in similar deployments and to save time.

Update Lists
Update lists are used to initiate deployments for a set of updates without having to manually select the updates in the set each time a new deployment is created, or each time the updates are added to an existing deployment.

Search Folders
Search folders provide an easy way to retrieve a set of software updates that meet the defined search criteria e.g. all Microsoft updates that have been deployed.

Require secure key exchange enabled by default

Most customers that enabled the require secure key exchange setting in SMS 2003 suddenly got stuck when deploying new secondary sites and couldn't figure out why the secondary site was constantly in the pending state.

I expect a lot more people deploying Configuration Manager will hit this issue as the require secure key exchange setting is now enabled by default.

If you’re experiencing this issue then the inboxes\despoolr.box\receive folder on the parent site will begin to fill up with files from the secondary site and the Despool.log file on the parent site will log entries similar to:

“Cannot find a public key for instruction C:\SMS\inboxes\despoolr.box\receive incoming from site S01, retry it later”
“Cannot find valid public key for key exchange instruction coming from site S01”

That’s assuming you’ve installed ConfigMgr to C:\SMS and the secondary site code is S01 of course.

You will also receive status messages for the SMS_DESPOOLER component on the receiving site.

The solution is to exchange the keys manually using the Preinst.exe tool.  The following article discusses how to do this as well as mentioning a few other scenarios where this is necessary:
https://www.microsoft.com/technet/prodtechnol/sms/smsv4/smsv4_help/45918ca7-891a-4551-99f6-b4daf41b58e5.mspx?mfr=true

ConfigMgr TAP/Beta Users: Are these the default settings?

... if you weren't a TAP or beta customer for ConfigMgr 2007 you can safely ignore this post, unless you're a bit bored and want to read it anyway.

The sharp eyed ConfigMgr 2007 TAP and beta users amongst you will have seen the email from Microsoft Connect, but this is fairly important news if you missed it. 

A bunch of site and client settings were changed from build to build before release.  If you install a build from scratch or upgrade from SMS 2003 then you'll get the default settings.  However, if you upgrade from previous builds then you don't get the latest default settings, rather the same ones you had before. This would for example happen if you upgrade from the RC to RTM build.  This makes sense really as the upgrade doesn't know if the setting was something you actually wanted and had configured yourself.

Microsoft has released some documentation and scripts on the Connect web site.  The documentation details the settings in question and the scripts can be used to set things to their RTM defaults.

Everything you need is on the Microsoft Connect site here.