A while back I had implemented Cumulative Update 1 (CU1) for System Center 2012 Configuration Manager Service Pack 1 in my lab environment. This post was published earlier on my SCUG blog and describes the implementation details and findings during the rollout of the CU. With the release of CU2 recently, I am aware that I am running behind with posting this, but as the implementation process for this CU will be very similar I decided to still post this information.
An overview of the issues fixed in this CU are outlined in the following article: http://support.microsoft.com/kb/2817245/en-us .
This is also the location where you can download the installation binaries from.
As per the documentation this CU is applicable directly to the following components:
- Primary Sites
- Secondary Sites
- SMS Provider
Additionally it contains updates for the following components:
- Primary Sites
- Secondary Sites
- SMS Provider
Let’s continue with the details on the actual implementation. Note that in the lab environment there is only a Standalone Primary site. There is no CAS or secondary sites to which the CU is to be applied.
Make sure all open console connections are closed and run the installer:
Click Next on the welcome screen.
Accept the license terms and click Next.
The prerequisite checker will run some initial checks. Click Next once all checks are successful.
Leave the option to update the database and click Next.
Leave the option to create the packages – these will come in handy for updating the other components in your Configuration Manager infrastructure.
Modify the Server package details if needed. Click Next.
Modify the Console package details if needed. Click Next.
Modify the details for the Client packages if needed. Click Next.
Review the installation summary and click Next to start installing.
Click Next once all installation tasks have completed successfully.
Click Finish. In my lab a reboot of the server was required.
Note that the site version remains unchanged after implementing CU1.
The CU1 is listed in Control Panel > Programs & Features.
The packages for upgrading the other components have been created successfully.
At this point do not forget to distribute the content to your Distribution Points.
This concludes the upgrade of the site itself. Now we can further upgrade the remaining components in our infrastructure.
Note that you have to deploy the console update also to the site server if the console was installed locally.
For deploying the CU1 to all consoles I had created a query based collection. This is the query that was used:
- select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_
Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceId = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Microsoft System Center 2012 Configuration Manager Console"
Deploy the console update package to the collection to update all remote consoles.
Once the CU1 for the console is installed it is also listed in Control Panel > Programs & Features:
Also for the clients I have created query based collections to deploy the CU1.
This is the query for the collection containing all x86 SP1 clients:
- select * from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.ClientVersion = "5.00.7804.1000" and SMS_G_System_SYSTEM.SystemType = "X86-based PC"
For the x64 clients I used the same query but replaced “X86-Based PC” with “X64-based PC”
Deploy the client update packages to the x86 and x64 client collections to update all existing clients.
The client version is updated to 5.00.7804.1202 once the CU1 has been applied:
To keep track of different client versions and for easy targeting in the future (additional hotfixes and updates) I also created collections for my SP1 CU1 clients.
This is the query for the collection containing all x86 SP1 CU1 clients:
- select * from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.ClientVersion = "5.00.7804.1202" and SMS_G_System_SYSTEM.SystemType = "X86-based PC"
For the x64 clients I used the same query but replaced “X86-Based PC” with “X64-based PC”
This concludes the implementation of System Center 2012 Configuration Manager SP1 Cumulative Update 1 in my lab environment.
ConfigMgr 2012 Prereq Checker warning: Verify site server permissions to publish to Active Directory
During installation of Configuration Manager 2012 RC2 the prerequisite checker lists a warning for the prerequisite: Verify site server permissions to publish to Active Directory although the required permissions are in place.
As the environment might expand and more site servers could be implemented it was opted to grant the permissions using a domain local security group which has the site server computer account added as a member.
First check was to verify if the required permissions on the System Management container are implemented for the group. Additionally it was confirmed the site server computer object was added as a member. When running the prerequisite checker it still shows the warning even though permissions are in place.
In a second scenario permissions were implemented on the System Management container using the computer object instead of using groups. When re-running the prerequisite checker it did no longer show the warning and passed the check.
According to feedback received this is behaviour as expected.
This was logged earlier as a bug for the RC1 release of Configuration Manager 2012. The bug report mentioned this would be fixed as of build 7688. Apparently at that point the fix was to reword the explanation offered by the prerequisite checker as opposed to implementing a fix that would have to create a dummy object in AD to test actual permissions.
Bottom line: the warning message can safely be ignored as long as the permissions for the group containing the site server(s) are correctly implemented.
After being absent for a few of the previous CEP sessions I was happy to be able to attend the PCM and P2V Toolkit session yesterday. Below are some key takeaways from this session. This was the last session for this year, next one is scheduled for January 11th 2012.
Package Conversion Manager (PCM)
PCM is a feature pack for Configuration Manager 2012 which will allow you to prepare and move your packages towards the new app model.
A best practice approach to convert packages would be:
- Migrate Objects
- Create apps in a lab environment
- Test apps in a lab environment
- Export and import
The package migration options from 2007 to 2012 are:
- Do nothing and leave the package and program
- Convert Manually
- Convert using PCM
Selecting conversion candidates:
- Good : App-v, MSI and Executable files (user facing applications)
- Bad: System maintenance tools (defrag, etc …) and end of life applications
Understanding PCM manual vs automatic conversion rules:
- Package contains only 1 MSI
- No unconverted dependencies exist
- Content is accessible
- Must have content
- Is a software distribution package
- Contains at least one program
- Using the conversion dashboard
- Advanced troubleshooting: using the pcmtrace log in the %temp% folder
PCM is scheduled to be released at the same time as Configuration Manager 2012.
Configuration Manager P2V Migration Toolkit
A utility to help migration to Configuration Manager 2012 in specific scenarios, for example a remote site server migration where the goal is to re-use existing server hardware.
How can the P2V toolkit help:
- Eliminates the need of parallel physical servers at remote sites
- Repurpose existing site server into a virtual instance
- Hosting ConfigMgr 2007 AND ConfigMgr 2012 on the same physical machine using virtualization
- Simplifies and automates creation of a virtualization task sequence
- Simple and intuitive interface to create and deploy the task sequence
- All virtualization tasks sequence steps are built-in
- Limited input needed by remote site administrators
- Task Sequence with stand alone media (fully automates the end-to-end process)
- Bootable media only
Offcourse the hardware should meet the necessary prerequisites for virtualization and Hyper-V.
The P2V toolkit will ship at the same time of Configuration Manager 2012 RTM as a separate tool.
The release candicate is already available via Connect.
Recently I have ran into an issue at a customer site where software update lists did not properly replicate down to child primary sites. Some of the latest update lists were either incomplete or not visible at all. As a result the customer could not properly advertise the latest software updates.
Initial investigation of the problem shows that the objmgr.box\INCOMING\ and objmgr.box\INCOMING\Retry folders on the child sites contained a lot of unprocessed CID and SDM files. Looking further into the objreplmgr.log errors like to one below are logged:
Processing replication file C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM in retry.
Successfully processed Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3
SDM Package ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3 does not exist in the DB, will insert it with the IsDeleted Flag Set.
SQL MESSAGE: sp_SetupSDMPackage – SDMPackage refers another SDMPackage that is not available yet
sp_SetupSDMPackage returns an error 2
Referenced SDMPackages are not available yet: http://schemas.microsoft.com/systemsmanagementserver/Site_43C9B1DB-9FC7-4363-8027-36D0C5C24148/SUM_cee535ab-0ae5-44e7-8fdf-0f698b27e6f9/1(0);
Failed to Delete Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3. Will add the Replication File C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM to the Replication File Retry Queue.
Similar errors exists when the site is processing .CID files.
Interdependencies exists between the different items used for software updates. If the referenced objects are not available the new file will not be correctly processed. It seems that for this particular child site a hickup occured in the replication and the information on the child site is incomplete.
To resolve the issue I ran through the following steps:
1. Stop the SMSEXEC and SMS COMPONENT MANAGER services. This will bring all activity on the site to a standstill.
2. Rename the INCOMING folder to INCOMING_old and recreate an new empty folder structure (so INCOMING and all retry/bad subfolders).
This way we can monitor which files are replicating down and if they are properly being processed, and also see what is being moved into the retry and bad folders.
3. Run the following query on the child site database: Delete from CI_ConfigurationItems Where CIType_ID in (1, 6, 8);
Note that the ID’s may be different for each site. Run the query Select * from CI_Types to get the proper list.
We need to delete the following types: SoftwareUpdate, SoftwareUpdateBundle and AuthorizationList
4. Then run this query: Update CI_SDMPackages set IsDeleted = 1 where SourceSite = ‘XXX’;
Make sure to replace the XXX with the site code of the central site in the hierarchy.
5. And execute the following: Exec sp_DeleteOldSDMPackageData 0;
6. As a final step force a full replication by dropping a XXX.SHA file in the objmgr.box folder on the central site
Here XXX is to be replaced with the site code of the child site.
7. Restart the services stopped in the first step to bring the site back in operational mode.
Shortly after these steps you should see files appearing in the objmgr.box\INCOMING\ folder on the child site again. You can also see if they are being processed in the objreplmgr.log file. Do not be alarmed if initially some files are put in the retry folder again. They will eventually be processed when all dependencies are in place. A full replication can be time consuming: in my case it took over 12 hours for the procedure to complete. Eventually the end result was that the Update Lists showed up completely again.
Note: the above procedure includes making direct changes to the backend database. If you have a support contract I would highly recommend to involve a Microsoft Support representative to ensure you infrastructure remains supported.
Some key takeaways from the CMCep session held on the 10th of August. Topic for this session was the ConfigMgr 2012 SDK, presented by Heena Macwan and Martin Dey.
- After MMS: SDK Beta program started. On invite only.
- ConfigMgr 2012 Beta 2 RTM time: SDK Beta available on Connect). Initial draft SDK, including:
- Coverage for the new AppModel classes and members
- Draft porting guide
- ConfigMgr 2012 RTM time: SDK Update, including:
- Details of all modified classes and members to help port existing solutions
- ConfigMgr 2012 RTM + 6 Months: SDK RTM
- Details on all new members and classes
- Samples and how-to’s
SDK Extension Areas
- Admin console
- Add right-click options, forms, wizards, nodes and views
- Insert tabs into existing forms
- SMS Provider
- Enabling automation of any UI activity
- Actions achieved through WMI classes, properties and methods
- MP interface
- Allows unsupported clients to be managed through proxy (MP Proxy)
- Provide extra support for windows clients
- Client interfaces
- Exposes interfaces to control panel applet
- Ability to enact custom policies at the client
- Note: client inventory customization no longer required
Porting from 2007 to 2012
- Some areas will require changes to port to 2012
- Guidelines will be made available.
New Extensibility Areas in 2012
- Application model
- Settings Management (formerly DCM)
- Data Warehouse
- Mobile Device Management
- Alerts and Monitoring
- Software Update Management
- Client Health
- Phase 1 available at ConfigMgr 2012 RTM : Drive Namespace context and support for get-item access by Object Type
- Phase 2 at 2 2012 : cmdlets covering key CM WMI namespace objects
In March round 2 of the Configuration Manager 2012 Community Evaluation Program was kicked off. It was announced that during this round the topics of the earlier round would be recycled but based on the Beta 2 release of ConfigMgr 2012. I intend to also participate in this round and share key takeaways for each of the CEP sessions.
Two days ago the session on ConfigMgr Hierarchy was scheduled. Presenter for this session was D.C. Tardy, senior Program Manager. Below you can find some key takeways:
- Modernized Architecture
- Minimizing infrastructure requirements for remote locations
- Consolidating infrastructure for primary sites
- Improvements related to scalability and data latency
- Being Trustworthy
- Interactions with SQL DBA are consistent with ConfigMgr 2007
- ConfigMgr Admin can monitor and troubleshoot replication approach independently
- Clients are managed through primary sites, not the CAS
- CAS is needed when:
- There is more then one primary site in a hierarchy
- There is a requirement to offload reporting and administration from the primary site
- Add primary sites for:
- Scaling (100.000+ clients)
- Reduce impact of site failure
- Local point of connectivity for administration
- Political reasons
- Content Regulation
- Use secondary sites for:
- Managing upward going WAN traffic
- Tiered content rooting for deep topologies
- Location without local administrators
- Add local DP’s for:
- Situations where BITS is not sufficient for controlling WAN traffic
- OSD Multicasting
- App-V Streaming
- New for DP’s:
- One DP type
- Can be hosted on client and server OS’s
- Throttling and scheduling features
- PXE / Multicast capabilities
- Drive specification for content storage
- Requires IIS feature
- New functionality in ConfigMgr 2012
- One feature that can preload on site server or DP
- Supports all package types
- Content library and package share
- Registers package availability with the site server
- Conflict detection to ensure latest package versions are used
Forest Discovery & Boundaries
- Forest Discovery
- Discovery at the site server forest level and any trusted forests
- Ability to manually add forests that are not trusted (eg DMZ scenarios)
- Returns the domains, sites and IP Subnets
- Supports the creation of boundaries (can be automated)
- Same types are in ConfigMgr 2007
- Simplified management
- Automatic creation as part of forest discovery
- Split between client assignment and content lookuo
- Boundary groups for organizing boundaries in logical containers
- Boundary groups are the primary object for client assignment and content lookup – not the boundaries!
- Auto-create boundary groups when migrating from ConfigMgr 2007
- One site per SQL instance
- All database communication is encrypted
- TCP/IP port for service broker
- Approach change
- Essential to stop use primary sites for different client settings
- Default client settings for the entiry hierarchy and custom settings assigned to collections
- Custom settings overrule default settings. Priority based.
Role Based Administration
- Remove clutter: goal is to only display what is relevant to the current user
- Security roles determine what objects a user can see and what he can do with them
- Security scope: what instances can I see and interact with
- Collections: which resource can I interact with
- Assigning a collection to an administrator automatically assigns all limited collections
- Product ships with only 2 read only root collections
- Every collection is limited by another
- All Systems
- All Users & User Groups
Some key takeaways from the CEP session on migrating from Configuration Manager 2007 to Configuration Manager 2012. Session hosted by Eric Orman and Jeroen van Eesteren, both from Microsoft.
How migrations were commonly handled in ConfigMgr 2007:
- Clients were reassigned and updated
- Objects were migrated using scripts and custom tools
- Infrastructure was implemented side by side
- Inventory data was either regenerated or preserved
What ConfigMgr 2012 will offer in regards of migration:
- Assistance for migrating objects and clients
- Minimizing WAN impact
- Flattening the ConfigMgr hierarchy
- Maximizing the re-usability of x64 hardware
Migration functionality will come out-of-the-box with ConfigMgr 2012:
- Automated object migration (collections, packages, boundaries, metering rules, etc …)
- DP sharing: fallback to ConfigMgr 2007 DP for obtaining migrated content
- Content prestaging (similar functionality as the PkgPreLoadOnSite utility)
- Distribution point upgrade to reduce requirement to redistribute content
High-level migration steps:
- Enable migration by specifying a ConfigMgr 2007 source central site
- Enable DP Sharing
- Define migration jobs
- Upgrade and re-assign clients to a ConfigMgr 2012 site
- Distribute or leverage DP sharing for deployment of migrated objects to new 2012 clients
- After client migration start distributing content to ConfigMgr 2012 DP
- Decommission ConfigMgr 2007 Infrastructure
Objects supported for migration:
- Software Packages and Virtual App packages
- Software update objects: deployments, deployment packages, templates and update lists
- OSD objects: boot images, driver packages, drivers, images, packages and task sequences
- DCM / Settings Management elements: Baselines and CI’s
- Asset Intelligence customizations
- Software Metering Rules
How to prepare your environment for migration:
- Get to the ConfigMgr 2007 SP2 level as a minimum
- Collections best practices:
– Avoid using mixed collections containing users and devices
– Avoid collections using multiple query rules which limit to different collections
- Use UNC paths for defining package sources. Avoid using local paths.
- Site codes must remain unique between ConfigMgr 2007 and ConfigMgr 2012 sites