To summarize in front, what you should take into account before starting your installation:

1. Make sure that the SQL administrators are aware that during installation extra righs are needed and that after installation the Site server must stay local administrator on the cluster nodes
2. Make sure that the SQL administrators are aware of the fact that ConfigMgr will install a service on the Cluster Nodes, which is used for creating the backup using VSS
3. Make sure that each shared cluster disk contains a no_sms_on_drive.sms file on the disk
4. Configure the Site Backup tasks, so that it is either configured to backup to an UNC path or a drive which is suitable for storing the backup files on both the site server and the cluster nodes using the “Different Paths for the Site Backup and Database backup” option

(more…)

First off all, before you can even start the installation, you must make sure the following prerequisites are taken care off:

• The computer account of the site server and the account used to execute the installation should be made local administrator on all the cluster nodes.

• The user running the ConfigMgr installation must have sysadmin rights on the instance of the remote SQL server

• The correct Service Principal Names must be registered in Active Directory

Please note that after installation, the user performing the installation can be removed from the local administrators group on the cluster nodes, and its sysadmin rights on the SQL instance can be removed.

Before actually starting the installation, you should run the prerequisite checker in order to determine if al prerequisites are met.

The installation procedure creates the database on the SQL cluster, including the necessary rights for ConfigMgr to function normally, unfortunately there is no SQL script available to create the database upfront.

The installation also installs a service on each of the cluster nodes, used for backing up the database. This service is called SMS_SITE_SQLBackup_<machinename> and this service is reponsible for creating the database backup, which you configure as a maintenance task later on.

There are two caveats here, which aren’t clearly explained in the documentation on technet:

1. First of all, the service is installed on the disk which has the most free space available, and ConfigMgr setup doesn’t take into account whether this disk as a cluster resource or not. In order to prevent ConfigMgr to install its binaries on a cluster shared disk, make sure that you create a no_sms_on_drive.sms file on each of the cluster disks before starting the installation of ConfigMgr
2. As just mentioned, you configure the backup using a maintenance task. When configuring this maintenance task, you also provide a location to store the backup. In this case though, the location on where to store the backup files should be configured differently between the Site server and each of the cluster nodes. You can accomplish this by choosing the “Different Paths for the Site Backup and Database backup” option and provide a suitable location on where to store the backup files.

The above solution has some disadvantages though, if you choose a cluster shared disk to store the backup files on the cluster, there is no problem. But if you choose a local disk you should be aware that the most recent SQL backup resides on the drive of the cluster node which was the owner of the resource at the time the backup was made.

It may be better to store the backup on a central location though, so that you have one location which you backup using your normal backup solution. In order for this to work, you should choose the option: “Network path (UNC Name) for site data and database”

Keep in mind that when using UNC Backup, that you need to authorize the computer accounts of the Site server and each cluster node, with write access to the share.

What to do if you forgot this upfront:

At the blog of the Mad Virtualizer, someone who provides Virtualization and Manageability Support at Microsoft, I found a solution to a similar problem, for me the solution worked a little bit differently, so therefore i described the solution the way i implemented it below.

If you didn’t put the no_sms_on_drive.sms file on each of the cluster shared disks, and you only have a C: drive on your cluster nodes, there is a big chance that on the non-active cluster node the files needed for the backup service are installed on the c: drive, and on the active cluster node on the shared cluster disk with the most free space available at that time. As long as the resources stay on that node nothing is wrong, but once the cluster resource moves, things start to go wrong resulting in non-working backups.

In order to reconfigure the cluster node so that the files are installed locally instead on a cluster shared disk you should use the following procedure to reconfigure the server:

1. Stop the SMS_Site_SQLBackup_<site server name> service on the cluster node on which the binaries are installed on a shared cluster disk
2. Remove the following registry key on the cluster node (make sure you make a backup first in case something goes wrong) HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\SMS\Components on a 64-bit installation or HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components on a 32-bit installation
3. Browse to the following registry key on the site server:HKLM\Software\(Wow6432Node\)Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\<cluster node name> and modify the value of path to a path on the C: drive
4. Browse to the following registry key on the site server: HKLM\Software\Microsoft\SMS\Components\SMS_SITE_Component_Manager\Multisite Component Servers\<cluster node name>\SMS_Site_SQL_Backup and modify the value of “Installed At Least One File” to 0
5. Restart the SMS_SITE_COMPONENT_MANAGER service on the Site Server
6. Monitor the Sitecomp.log file on the site server for succesfull installation can be found in the ,<ConfigMgr installation folder>\Logs folder
7. Check the backup by starting the SMS_SITE_BACKUP service on the Site server and checking the logfile to determine if the backup succeeded.

References:

How to Install Configuration Manager Using a Clustered SQL Server Instance- http://technet.microsoft.com/en-us/library/bb680513.aspx

Prerequisites for Installing Configuration Manager – http://technet.microsoft.com/en-us/library/bb694113.aspx

Setup Prerequisite Checks – http://technet.microsoft.com/en-us/library/bb680951.aspx

Troubleshooting Duplicate or Missing SPNs for a ConfigMgr 2007 SQL Database – http://blogs.technet.com/b/configurationmgr/archive/2010/10/26/troubleshooting-duplicate-or-missing-spns-for-a-configmgr-2007-sql-database.aspx

How to Prevent Configuration Manager From Installing Files on a Specific Drive – http://technet.microsoft.com/en-us/library/bb632890.aspx

SCCM (Configuration Manager) Installed Component Provider Binaries on SQL Clustered Drive (or other shared clustered drive) by Mistake. – https://madvirtualizer.wordpress.com/2011/01/14/sccm-configuration-manager-installed-component-provider-binaries-on-sql-clustered-drive-or-other-shared-clustered-drive-by-mistake/

Backup ConfigMgr Site Server Task Overview – http://technet.microsoft.com/en-us/library/bb633003.aspx

How to determine the Policy Settings:

In order to determine the correct settings, its best to build ConfigMgr in a test environment, where the servers are isolated from Group Policies when you are installing them. Start with detailing the configuration of the Security Settings of the machine in the state which you received it, or just after you installed the machine yourself. This can be easily done by exporting the User Rights Assigment and the Security Options settings using the Export List… options when you rights click the User Rights Assignment or Security Options node. Save the output, and make sure you detail the fact that this settings reflect your start position. (more)

The Second step should be that you configure the requirements needed on the Server in order to be able to install Configuration Manager, like IIS, WSUS etc.. (detailed here). When finished repeat the same procedure and make sure you name the output files to reflect the pre ConfigMgr installation state.

The Third step, is the ConfigMgr installation itself, install ConfigMgr and make sure the Site (or site system) is working properly. Repeat the described procedure and make sure you name the output files to reflect the post ConfigMgr installation state. There are probably more ways to achieve this goal, but this works with out of the box functionality.

The outcome of my investigation, which is the difference between the first and the last output saved, resulted in the following settings:

User Rights Assignment:

Adjust Memory Quotas for a process: Add Classic .NET AppPool,DefaultAppPool

Generate Security audits: Add Classic .NET AppPool,DefaultAppPool

Impersonate a client after authentication: Add IIS_IUSRS

Log on as a batch job: Add IIS_IUSRS

Log on as a service: Add Classic .NET AppPool,DefaultAppPool

Replace a process level token: Add Classic .NET AppPool,DefaultAppPool

Security Options:

Network access: Remotely accessible registry paths and sub-paths: Add Software\Microsoft\SMS

Keep in mind, that when you configure a so called Delta Policy for your ConfigMgr servers – which only contain the settings needed for that type of machine, you have to provide the default settings plus the above settings in the policy in order for the setting to be applied successfully.

The Caveat (without it it wouldn’t be fun…)

As always, when implementing these settings you run into some other “Challenges”, in my case it was because of the fact that the IIS Classic .NET AppPool and DefaultAppPool accounts weren’t added successfully to the registry after applying the newly configured policy. When you run a GPResult /H Report.html the report details that the settings are successfully applied, but when opening the local policy editor (Gpedit.msc) or the Resultant Set of Policy tool (RSOP.msc) when troubleshooting further you will notice that the settings are not applied.

The fact that the settings are not applied is also logged in the Application event log and searching for eventid 1202, resulting in the following error:

You can also see how Group Policies are applied by looking at the winlogon.log file created in the %windir%\security\logs\ folder during logon.

Configuring SeImpersonatePrivilege for this account is not supported.

Configure Classic .NET AppPool.

Error 1332: No mapping between account names and security IDs was done.

After this, then Google or you other favorite search engine is your friend, eventually resulting in finding the following KB article 977695: http://support.microsoft.com/kb/977695

The KB Article describes that when the Group Policy Management Editor changes settings under User Rights Assignment, it translates per-Service SIDs to service names, it does not add the NT Service or IIS AppPool prefix when doing so though, resulting in the behavior that only the supplied name in the Group Policy Management Editor (for example Classic .NET AppPool) is written to the GptTmpl.inf file while this should be IIS AppPool\Classic .NET AppPool instead.

The KB Article provides two solutions, by either requesting a hotfix to fix the Group Policy Management Editor, or by manually editing the GptTmpl.inf file. I decided to just the last option to edit the GptTmpl.inf file directly (search for the GUID of the Policy, and locate the correct .inf file)

[Privilege Rights]

SeIncreaseQuotaPrivilege = IIS AppPool\DefaultAppPool,IIS AppPool\Classic .NET AppPool,*S-1-5-32-544

SeAuditPrivilege = IIS AppPool\Classic .NET AppPool,IIS AppPool\DefaultAppPool

SeBatchLogonRight = IIS_IUSRS

SeServiceLogonRight = IIS AppPool\Classic .NET AppPool,IIS AppPool\DefaultAppPool

SeAssignPrimaryTokenPrivilege = IIS AppPool\DefaultAppPool,IIS AppPool\Classic .NET AppPool

SeImpersonatePrivilege = *S-1-5-6,IIS_IUSRS,*S-1-5-32-544

After modifying the GptTmpl.inf file and running a GPUpdate /force, i was able to check a Resultant Set of Policy, which gave the expected result.

Challenge solved

System Center Configuration Manager 2012 has a built-in health feature to repair the client. The program is called Ccmeval.exe and can be found in the folder C:\Windows\Ccm. When the client is installed a scheduled task is created on the client computer to run this program daily. This means that a client should not be dysfunctional for more than 1 day.

Let see if this works.. (more)
I have a Configuration Manager 2012 environment with a computer where the Configuration Manager client is installed. When we look at the properties of the Configuration Manager client we see that most tabs are empty, meaning the client is not function as it should.

This client must be repaired in order to restore communications with the site. We can wait for the schedule task to run but in this case I run the Ccmeval.exe manually to trigger the repair process. We can track the process of repairing the client. We can this this by tracing the log file: C:\Windows\CCM\Logs\CcmEval.log.

In the log file you can see that the client health mechanism has determined that the WMI is corrupted on the client. To fix this the SMS Agent Host service is reinstalled from the client locally. Note that it is not installing from the management point. After the client is repaired the client will automatically create a DDR(Discovery Data Record) and sent this heartbeat DDR to the management point. After the Site server has processed this request the client is healthy and will receive policies again. The verify this we open the properties of the Configuration Manager in the Control Panel. As you can see the tabs are now filled with the properties of the site.

Conclusion: The client Healt feature in Configuration Manager 2012 is very welcome. it keeps the client connected to the site. When for some reason the client is not function well it gets automatically repaired.

The System Center Orchestrator Beta marks a significant milestone, indicating a move of the codebase from the Opalis subsidiary to Microsoft System Center. This has many positive benefits, including a removal of the licensing complexity around the ‘grant’ of Opalis, greater alignment to the Microsoft Common Engineering Criteria and also things like the Support Lifecycle. (more)

If you would like to take the new Beta for a spin, al you need to do is sign up here and they will contact you when the program starts in June. The evaluation program will take you on a guided tour of the Orchestrator Beta, providing documentation on a variety of topics, a ready made environment if you just want to spin up quickly (although the new Installer is very quick and easy!) and regular access to the Orchestrator product team.

The table below contains some more detailed information about the system requirements and other features of Orchestrator. The table below is designed to highlight the key changes being made for the Orchestrator release, and also any differences between the Beta and RTM.

So what more will we see in System Center Orchestrator?

• Dynamic Silverlight console
  • Consistency across Versions
  • Opalis 6.3 & Orchestrator
  • PowerShell
  • Protection of existing investments in Opalis 6.3
• Powerful Web Service
  • Interface from anywhere to System Center
• Reporting
  • No new interfaces, just leverage of existing structures
• Script based interaction with System Center Orchestrator

Want to know more? Visit Jakob’s blogpost or visit the official Microsoft blogpost. Below are some screenshots of the upcoming System Center Orchestrator release:

• Out of the box discovery, monitoring, and reporting
• Server to network dependency discovery
• Multi-vendor support
• Multi protocol support
• SNMPv1/v2c/v3
• IPv4 and IPv6
• Robust platform for partners to build on

The first step to get monitoring working is to run the Discovery Wizard (the process of identifying network devices to be monitored). The network monitoring bits have been re-written from the ground up, so although the Discovery Wizards looks somewhat similar it actually allows you to use all these new features such as SNMP v3 and IPv6 support. So what is acutally discovered? (more)

• Connectivity
• VLAN membership
• HSRP groups
• Stitching of switch ports to server NICs
• Key components of a device
• Port/Interface
• Processor
• Memory

The new discovery process has three stages: (1) Probing, (2) Processing and (3) Post Processing. It has two modes: Explicit and Recursive (using ARP, IP or Topology MIB).

The discovery works only on Gateway/Management Server and has a single rule per Gateway/Management Server. The discovery runs on a scheduled basis or on demand.

One nice new feature is that we can do “limited discoveries” which can be triggered by device traps from certain device vendors, such as Cisco!

Once your device gets discovered, what do we actually monitor? Out of the box you get:

• Port/Interface
  • Up/Down (operational & admin status)
  • Volumes of inbound/outbound traffic
  • % Utilization
  • Drop & Broadcast rates
• Processor
  • % Utilization
• Memory
  • In depth memory counters (Cisco Only)
  • Free memory

Other than those, we will monitor Connection Health (based on looking at both ends of a connection), VLAN Health (based on health state of switches in VLAN) and HSRP Group (based on health state of individual HSRP end points).

As you might have heard, System Center Operations Manager 2012 is introducing the concept of “pools” (which we’ll talk about in a later blogpost). Network Monitoring supports these pools of management servers. So what else is cool? Well:

Only certain ports will be monitored by default! These will be ports connecting two network devices to each other or ports to which managed server is connected.

Ofcourse, users can enable monitoring for other ports if above is not sufficient.

In System Center Operations Manager 2012 we’re also introducing the concept of “dashboards” (which again I’ll talk about in a later blogpost).

Network monitoring has four dashboards out of the box:

• Network Summary
• Network Node
• Network Interface
• Vicinity

And ofcourse it’s going to provide out of the box reports: Memory Utilization, Processor Utilization, Port Traffic Volume, Port Error Analysis and Port Packet Analysis.

Stay tuned for more blogposts on System Center Operations Manager 2012!

The windows Azure platforms consist of 4 main parts:

• Windows Azure
• Windows Azure AppFabric
• Connect
• SQL Azure

David explained how these 4 main parts make the Windows Azure platform. An interesting discussion with cloud computing is that companies are afraid to put their mission critical data on the internet. According to David most people when they think about cloud computing they think of their mission critical data. It would be better to start first with less critical data and build trust for the future.

At this moment Microsoft has 6 datacenter across the world where the Windows Azure platform runs: 2 in the USA, 2 in Europe and 2 in Asia. The Windows Azure platform has lots of interesting techniques like the Windows Azure Traffic Manager which you can use to redirect users across the world to the best available datacenter. Datasync, Service Bus, Access Control, Caching etc. are all important things when you are going for the Windows Azure platform. David explained all these items very thoroughly but that is too much info for here.

For a good impression take a look at the pictures I took of the session:

Could not attend the session? Here’s the recording:

Keep a close eye on our website and twitter stream for Teched updates as they happen!

• Windows 2008 R2 x64
• System Center Operations Manager 2007 R2
• AVIcode .NET Enterprise Management Pack 5.7 for Operations Manager
• Microsoft Visual Studio Team Explorer 2010
• .NET Framework 4.0

How does it all work? Well, Avicode monitors the .NET application from within System Center Operations Manager and raises alerts when things (are about to) go wrong. Through the connector framework, Alerts are sent to TFS and created as an ‘operational issue’ (work item). The developer uses Visual Studio to follow-up and gets a direct link into Avicode to view the exact error, context, etc. (more)

Here’s a global view (click on it for full size):

During the installation of the SCOM-TFS Connector, it installs the following components:

• TFS Connector Windows Service (Microsoft.Mom.TFSConnectorService.exe)
• TFS Communication Process (Microsoft.Mom.TFSConnectorInstance.exe)
• TFS Connector Management Pack (TFS Connector and TFS Connector (Templates) MP)
• TFS Connector Management Pack Template DLL (Microsoft.Mom.TFSConnectorCommon.dll)

TFS Connector Window Service

• It utilizes SCOM connector framework to retrieve Operations Manager alerts in ‘Assigned to Engineering’ status and sends them to TFS as operational issues via appropriate TFS Communication Process.
• It monitors for changes in alerts using SCOM SDK, and updates operational issues with the changes via TFS Communication Process.
• It monitors for changes in operational issues via TFS Communication Process, and updates alerts with the changes using SCOM SDK.

TFS Communication Process

• It hosts a WCF service for managing all TFS reading/wiring communication.
• It runs under the privileged account which is defined in a Run As profile inside SCOM. This Run As account is created automatically during TFS Connector configuration as part of Monitoring Template Wizard. This account is required to have sufficient permissions to create new work item types and manage work items.
  TFS Connector Management Pack and TFS Connector Management Pack Template DLL
• TFS Connector MP provides UI for configuring TFS Connector template, support queue management, connector configuration/troubleshooting dashboard. TFS Connector enables mapping of application components monitored using AVIcode .NET Enterprise MP to TFS projects. This allows routing of alerts associated with application components to appropriate TFS Operational Items queue.
• TFS Connector MP DLL provides custom UI for the TFS Connector Monitoring Wizard. It has to be installed on every computer that will be used for configuring TFS Connectors.

Here are some screenshots on installing and using the connector (click on the picture for full size):

• Exchange Virtualization Made Easy: Additional supported hypervisor scenarios for virtualized Exchange Server 2010, including Unified Messaging were announced today.  This combines Exchange’s high availability solutions, Database Availability Groups (DAGs) with hypervisor based clustering and failover solutions.
• Updated Exchange Server 2010 Microsoft Certified Master (MCM) program: Announced today, The Exchange Server 2010 MCM program allows Exchange Server 2010 experts to achieve MCM certification at a lower cost and with more flexibility by removing the barriers of travel and training time investment.
• New Features coming to Windows Phone 7:  New business features for mobile workers will be delivered in the next update of Windows Phone (code named ‘Mango’) to enable even greater productivity. Some of the forthcoming features being announced at TechEd 2011 including search enhancements in Outlook Mobile, out-of-the-box support for Office 365, and the new Lync mobile app.
• New License Mobility program: New license mobility options will become available on July 1, 2011 through Microsoft Volume License agreements with an active Software Assurance benefit were announced today.  The new options will provide customers with the flexibility to deploy application services on-premises or through hosted service providers in the cloud.
• Windows Server 2008 R2 Hyper-V support for Linux-based CentOS: Window Server 2008 R2 Hyper-V will support for Linux-based CentOS to provide customers who run mixed-environments consisting of Linux and Windows.
• The ALM vision in Visual Studio vNext: Microsoft announced its vision for Application Lifecycle Management (ALM) technologies in the next version of Microsoft Visual Studio. Microsoft described how its ALM capabilities will enable organizations to respond faster than ever to business needs and improve the flow of information between key stakeholders to plan, build and manage-applications.
• Microsoft System Center Operations Manager 2007 R2 connector for Microsoft Visual Studio Team Foundation Server 2010 CTP1: Microsoft announced a CTP of the new connector available in the next 30-60 days. The connector enables an operations team to send application performance monitoring information immediately to the engineering team for attention.

Keep a close eye on Techlog while we bring you the news live as it happens on the showfloor!