Stuart James at myITforum.com

Installing ConfigMgr R2 on Secondary Sites

I've seen this come up a few times now. After upgrading your primary sites to R2 you also need to upgrade your secondary sites.

This cannot be done by using the "upgrade secondary site" option. Also, if you push a new secondary site out from an R2 primary, the R2 bits do not get installed.

The secondary site always gets installed as an SP1 site and you then need to install R2 onto it before you'll see things like the Virtual Applications node in the DP properties.

You can either install it manually on the secondary site server, or you may prefer to push it out via software distribution if you have lots of secondary sites (it is just an MSI after all).

Server Virtualization Validation Program (SVVP)

Have you heard of the Server Virtualization Validation Program (SVVP)? 

It's a program whereby certain 3rd party virtualisation partners can validate certain configurations with Microsoft.  This means the customer can get Microsoft based technical support for systems running in 3rd party virtual environment. Current list is as follows:

Cisco Systems, Inc.
Citrix Systems, Inc.
Novell, Inc.
Oracle, USA Inc.
Sun Microsystems
Unisys Corp.
Virtual Iron Software
VMware, Inc.

You can find some info from VMWare here:
http://www.vmware.com/company/news/releases/svvp.html

Installing Windows Live Products on Server 2008

Having just installed Server 2008 64-bit on my laptop (mainly for Hyper-V) I'm now trying to make it as much like a desktop as possible.  One thing that doesn't work straight away is Windows Live products, as the standard wrapper like installer prevents installation.

My workaround has been to bypass the wrapper installation you are generally forced to use by building a 64-bit Vista VM in Hyper-V and then copying the MSI installers from C:\Program Files (x86)\Common Files\WindowsLiveInstaller\MSI Sources. You need to show hidden files to see them.

Once you have them just run the MSIs on Server 2008 and all installs fine.  It's not so easy to make out which product is which from the files names so below is the product and the first 4 characters of the GUID in the MSI file name:

Mail: 184E
Photo Gallery: 257E
Messenger: 508C
Writer: 9176
Sign-In Assistant: AFA4

Have so far tested Mail, Messenger and Live Writer and all worked OK. Of the installations give you notifications but some just run through with nothing to tell you it's done, so just check your start menu...

eSATA versus USB2

I make a lot of use of Virtual Server and Virtual PC (and soon Hyper-V) with my laptop and find the thing that seems to slow me down most is disk performance.  I don't have the storage on my main disk so run my virtual machines on USB 2.0 disks.  As my VMs get larger and busier the performance seems to get worse.

I therefore decided to take the plunge and get myself set up with eSATA.  I purchased the following:

eSATA ExpressCard: http://www.scan.co.uk/Product.aspx?WebProductId=676511

2.5" External eSATA/USB case: http://www.scan.co.uk/Product.aspx?WebProductId=603610 (note that this comes with all cables you need, including eSATA to eSATA)

2.5" Hard Disk: http://www.scan.co.uk/Product.aspx?WebProductId=773812 

Tests are performed using HD Tune 2.55 using a quick test.  It's the same disk just plugged in to a different socket so all other things (such as cache, RPM etc) are equal.

USB 2

eSATA

Quite a huge difference then on paper and I'm hoping it will make a big difference to the performance of my VMs.  I'll report back with some more subjective data on VM performance over the next few weeks.

Do your bit for the environment - free power management tool!

"Edison was developed by Verdiem, a company that has helped enterprises the world over reduce energy waste from IT devices. Now Verdiem is bringing Edison into your home—at no cost whatsoever. Download Edison and start saving energy today!"

http://www.verdiem.com/edison/

This is a free tool from Verdiem, whilst they also provide enterprise level power management solutions..

Preload Package Tool is Back!!

The popular tool from the SMS 2003 Toolkit but missing from the ConfigMgr 2007 Toolkit has now been updated and released as a stand-alone download:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c36fcda8-9336-4d44-9568-5530ff7635dd&DisplayLang=en

A great social experiment for the "anti-Vista" crowd

What do people think of Windows Vista when they don't know it's Windows Vista?

Have you heard of the Mojave Experiment?

The basic gist is that Microsoft take a bunch of Vista haters and show them their "new" OS that is "in development" to see what they think.  Really they are playing with Vista. Some very interesting results:

http://www.mojaveexperiment.com/

Using no_sms_on_drive.sms when installing on SQL cluster

SCCM setup has a habit of placing components on the drive it finds that has the most space.  if you're using a clustered SQL instance then this can often mean that components intended for non-shared disks end up on shared disks.

To prevent this from happening, place an empty file named NO_SMS_ON_DRIVE.SMS at the root of each drive where you DO NOT want it to install the components and it will avoid using those drives i.e. place it on all drives except where you want it to install the SCCM components.

Note we're talking about the SCCM components here, not the actual database itself. SCCM installs some components on each physical node to assist with things like backup.

Something to be aware of for SCCM SP1 Upgrades...

Thanks to Jeff Gilbert for the original post.

“Before beginning the upgrade process to Configuration Manager 2007 SP1, the Windows AIK 1.0 should be uninstalled from the SMS Provider computer for the site to allow SP1 Setup to install Windows AIK 1.1 to support SP1 OSD WIM images.

If the Windows AIK 1.0 is not uninstalled prior to beginning SP1 Setup, and a PXE service point is installed in the site running the Windows Deployment Services (WDS) Server service, the upgrade might fail and result in an unexpected restart and post-upgrade SMS Executive service crashes.”

http://myitforum.com/cs2/blogs/jgilbert/archive/2008/07/22/upgrading-the-windows-aik-for-configuration-manager-2007-sp1.aspx

How to Configure ISA SSL Bridging for System Center Configuration Manager Internet-Based Client Management

Some new documentation is now available on Technet: How to Configure ISA SSL Bridging for System Center Configuration Manager Internet-Based Client Management (http://go.microsoft.com/fwlink/?LinkId=122350). This has been a joint collaboration between the ISA Server product group and the Configuration Manager product group to provide guidance on how to configure the two products to work together to support Internet facing clients. 

This provides a higher level of security for Internet traffic than the alternative method of tunnelling, or tunneling if you're in the US :). With ISA bridging traffic from Internet clients is authenticated and terminated at the ISA Server, inspected, and then new SSL connections are made to the Internet-based site system servers.  This is as opposed to tunnelling, where the traffic from the Internet clients is forwarded to the site system servers without termination, so it cannot be inspected for nasty content.

ConfigMgr SP1 Released

http://technet.microsoft.com/en-au/configmgr/cc562979.aspx

System Center Configuration Manager Capacity Planner

An unofficial tool, but at least something to go on if you're starting a ConfigMgr design:

http://myitforum.com/cs2/files/folders/utilities/entry112970.aspx

Useful System Center Search Gadget

http://gallery.live.com/LiveItemDetail.aspx?li=49e26ad0-113d-4f3d-a711-57f6530c75d9

Description:

This gadget makes it easier to find help for Microsoft System Center products because it uses Live Search macros to search specific sites instead of the entire web. Search results are only returned from sites that are known to contain helpful information about System Center products. Use the settings in the gadget to pick the System Center product that you want to find information about, and then enter a search term in the gadget to get customized search results.

Mobile Device Management in the System Center Family

Ever since hearing about System Center Mobile Device Manager I've been thinking about the fact we now have two System Center products capable of managing handheld devices, this and ConfigMgr.  Why are there two products, how do they compare, and how do I understand which should be used in which scenarios.

Anyway, I found out that Eric Berg has written a good post that helps to understand some of this:

http://blogs.technet.com/systemcenter/archive/2007/11/02/managing-mobile-devices-with-system-center.aspx

Hopefully you'll find that useful as well...

Problem going back to SMS 2003

All of my virtual machines now have ConfigMgr installed, but I needed to test something on SMS 2003.  I therefore took a copy of one of my machines, uninstalled ConfigMgr and installed SMS 2003.  However, whilst the setup was OK the site was not operational.  The following error reported in sitecomp.log over and over:

CStatusModule::Initialize(): ERROR: Could not register this process as a source of "SMS Client" events, Win32 LoadLibrary("C:\WINDOWS\system32\smsmsgs\climsgs.dll") returned error 127

It seems that certain dll files are left behind after removing ConfigMgr, and because these are a later version they are not replaced by SMSSetup.  You'll find these in:

%windir%\system32\smsmsgs

Stop the sitecomp service, replace the dll files in this folder with the files from the SMS 2003 CD in D:\SMSSETUP\BIN\I386\SYSTEM32\SMSMSGS.  Start sitecomp again and you should be good to go. None of this is recommended in production but if you're just playing with test environment then maybe this will help you.

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.