System Center 2012 Licensing

Overview: Microsoft came up with the licensing model for System Center 2012 recently. Here I will discuss some of the key features of the MS licensing model that consultants and cloud evangelists can take to their customers.
Some of the key features of the MS licensing model include are:

1. High ROI: Microsoft cloud solutions are licensed on per processor model instead of virtual machine or memory model. I believe this is a very important criterion for selling MS cloud over VMWare since
   1. The cost to the customers does not increase linearly as the cloud landscape increases
   2. MS cloud solutions become more lucrative for our customers since the return of investment on MS based clouds will be higher
2. Simplicity: Microsoft licensing model is simpler to understand than my phone bills. There are 2 server management licensing models which are best suited for the small scale or large scale cloud adoption and are customer centric:
   1. Datacenter – Ideal for large scale cloud adoption
   2. Standard – Ideal for POCs or small scale cloud adoption
3. Consolidated: Though the System Center suite comprises of multiple products, the pricing for the products is consolidated thereby making System Center 2012 sell out like a single suite.

Per Microsoft's white paper on comparison between MS and VMWare cloud pricing:

• Microsoft based cloud would cost 1/5^th of a VMWare based cloud for a Medium sized business with 6VMs per processor
• 1/8^th for a Large Enterprise scenario with 6VMs per processor
• 1/16^th for a Large Enterprise with 15VMs per processor assuming 42 physical hosts

Server Licensing Models
Datacenter Licensing Model

• The datacenter licensing model gives unlimited virtualization capability
• This is good for clients opting for high density private clouds
• Each license covers 2 processors
• Requires minimum of 25 licenses to be purchased
• Includes software assurance that can be opted for 1, 2, or 3 years
• Datacenter Licensing includes the following System Center products:
  • Infrastructure Management
    • Configuration Manager (SCCM)
    • Endpoint Protection (SCEP)
    • Virtual Machine Manager (SCVMM)
    • Operations Manager (SCOM)
    • Data Protection Manager (SCDPM)
  • Service Delivery Automation
    • Orchestrator (SCO)
    • Service Manager (SCSM)
  • Application Management Interface
    • App Controller (SCAC)
    • Self Service Portals (This is the differentiator that service delivery companies should be eyeing at)

Standard Licensing Model

• The standard licensing model gives limited virtualization capability i.e. 2 operating system environments
• This is good for POC environments or early adopters of cloud who are looking at small implementations
• All capabilities of System Center 2012 are available with the Standard License
• Includes software assurance that can be opted for 1, 2, or 3 years
  

 Reference: Microsoft Licensing Datasheet

VMWare v/s Microsoft Cloud Product Comparison

Comparison of VMWare v/s Microsoft Cloud Product

Application Management Comparison

Services

Application Self Service

Application Performance Management

Application Management Across Clouds

IT Service Management

IT service reporting

Process Automation and Orchestration

Cloud Creation and Delegation

Data Protection and DR

Monitoring

Configuration and Compliance

Hypervisor and VM Management

Process Automation and Orchestration

vCloud Director

X

X

X

App Controller

X

vFabric Application Performance Manager

X

Operations Manager

X

X

X

vCloud Connector

X

Virtual Machine Manager

X

X

vmWare Service Manager

X

Service Manager

X

X

vCenter Operations Management Suite

X

X

X

Orchestrator

X

X

vCenter Orchestrator

X

Data Protection Manager

X

vCenter Site Recovery Manager

X

SCCM 2012 – How to catch errors in Task Sequence

Issue Description:
A key requirement with a task sequence is to intelligently capture logs in case of a failure or a success. Some of the key issues faced while working with task sequences are:

1. Log files in a task sequence hop from one folder to another depending on the OS installation and the SCCM Client Installation status.

Path of the log file	OS Status	SCCM Client Status
<largest fixed partition>\SMSTSLOG	Windows PE	Not Applicable
%temp%\SMSTSLOGS	full operating system	No
C:\windows\ccm\Logs	full operating system	Yes

1. This issue of hopping log files accentuates when the Task Sequence fails and it is difficult to locate the exact location of the log files.
   
    
2. It also becomes challenging to look for smsts logs when mass deployments are done. It is important to know how to manage logs for successes and failures, therefore the requirement is to copy the smsts.log to a central share and easily differentiate whether the deployment was a success or a failure
   
    
3. In addition, when a particular task of the sequence fails, there is an error prompt that stays for 15 minutes or so and the machine reboots thereafter. In case the administrator is not in front of the machine where the TS failed, he or she would not know upfront that there was a failure until he or she checks the log files. Therefore one requirement is to halt the task sequence where it fails

Solution Description:
Based on the above issues and requirements, the key tasks we need to accomplish are:

1. If the task sequence (TS) is a success, then
   1. The logs should get copied to a central share
   2. Into a folder called SUCCESS
   3. And the TS should complete gracefully
2. If the TS is a failure, then
   1. the logs should get copied to a central share
   2. into a folder called FAILURE
   3. Also the TS should halt immediately so that the admin can see that there was a failure

We will accomplish this requirement by using in-built variable in the task sequence - _SMSTSLastActionSucceeded. This variable captures the state of the last action and returns TRUE when the action was successful and FALSE when there was an error.

#	Description	Screenshot
1	Put the entire logic of the Task Sequence including OS install, application install, driver install, etc under a main group called MAIN TS At the same level of the Main TS, put another action called Try Catch Create 2 sub groups under Try Catch called: Success Failure The idea is to capture any errors that happen in the Main TS into that try catch action
2	Set "Main TS" group to Continue on error
3	Add a condition to the "Success" group: Evaluate whether the TASK SEQUENCE VARIABLE: _SMSTSLastActionSucceeded equals TRUE Here the variable _SMSTSLastActionSucceeded captures the status of the last task executed If there is a failure in the MainTS, the _SMSTSLastActionSucceeded will be set to false, else true The TS will enter Success group only if there are no errors in the previous tasks
4	Similarly, add another condition to the "Failure" group: Evaluate whether the TASK SEQUENCE VARIABLE: _SMSTSLastActionSucceeded equals FALSE The TS will enter Failure group only if there are errors in the previous tasks
5	Add the following logic under the Failure Group: Map a network drive -> say L: -to \\<servername>\LogFileShare\ This is the share where all the logs will get copied
6	Delete any folder associated with a computer name in the Failure Folder -> \\<servername>\LogFileShare\Failure\<computername> Add a Run Command Line tasks and put the following command in the command line: cmd.exe /c rd L:\Failure\%_smstsmachinename%% /s /Q Here %_smstsmachinename%% command refers to the computer name of the target computer This task is necessary to ensure all earlier logs corresponding to the machine are deleted
7	Create a new folder in the Failure folder for the computer name -> \\<servername>\LogFileShare\Failure\<computername> Add a Run Command Line tasks and put the following command in the command line: cmd.exe /c md L:\Failure\%_smstsmachinename%%
8	Copy the log files from the smstslog file path to \\<servername>\LogFileShare\Failure\<computername> Add a Run Command Line tasks and put the following command in the command line: cmd.exe /c copy %_smstslogpath%\*.* L:\failure\%_smstsmachinename%
9	Halt the Task Sequence by invoking a simple wscript.echo command Invoke a simple vbscript that prompts the path of the folder where the logs are kept: Script.echo "There is an error in the task sequence implementation. The log files are stored at \\<servername>\LogFileShare\"
10	Add similar tasks for group "Success"
11	Create a folder on the server for storing the logs and share it with Everyone Full Control Create 2 additional folders called Failure and Success
12	The Failure and Success folders will get populated with appropriate computer names

Impact of SQL Outage on System Center Configuration Manager 2012

Application Description
Microsoft SCCM is a set of tools and technologies that allows us to manage EUC systems and applications across the enterprise. SCCM include technologies that are used for application delivery, OS delivery, software, system and security auditing, security patching, and antivirus definition deployments etc.

It is important to note that this version of SCCM will be tightly integrated with App-V. Stand-alone App-V streaming infrastructure can be deprecated in favor of full integration with SCCM management tools and distribution points. That being the case SCCM 2012 high availability becomes an even higher priority than if it was only being used for traditional push deployments and management.

Database Storage and Performance Characteristics
<Database storage would typicall suffice an organization with 10,000 end user computing devices, 10,000 users, and 2000 applications>

Role	SQL Requirements
	Features Enabled	Purpose	Size
Tier 1 - SCCM CAS Site Server	o Database Engine Services o SQL Server Replication o Full Text Search o Analysis Services o Reporting Services o Integration Services o Management Tools – Basic o Management Tools – Complete	SQL Server 2008 R2 Database	100 GB
		SQL Server Log Files	50 GB
Tier 2 - SCCM Primary Site Server	Database Engine Services o SQL Server Replication o Full Text Search o Analysis Services o Reporting Services o Integration Services o Management Tools – Basic o Management Tools – Complete	SQL Server 2008 R2 Database	100 GB
		SQL Server Log Files	50 GB
Tier 3 - SCCM Secondary Site Server	Default	SQL 2008 Express	50 GB

 

Impact of Database Outage:
SQL databases are associated with the Central Administration Site Server (CAS) and the Primary Site Server.  Database outages at each of these tiers will produce different impact. In order to understand the impact of database outage it is important to understand the SQL replication topology of SCCM:

• Global Data Replication: Global data refers to collection rules, package metadata, program metadata, deployments, task sequence metadata, and configuration item metadata and site control file. The global data is replicated via SQL across CAS, Primary, and Secondary Site Servers.
  
• Site Data Replication: Site data refers to collection membership results, alert messages, hardware inventory, software inventory and metering, status messages and client health data. The site replication data is replicated between the CAS and Primary Site Server only.
  
• Content Replication: Content replication refers to replication of the package media. Content replication is file-based and SQL has no impact on the physical content.
  

Impact of Database Outage at CAS

If the database is down at the CAS the following impact will be seen:

• Impact for Administrators:
  
  • Administrators will not be able to connect to the SCCM console that is connecting to the CAS
    
  • Administrators already accessing the SCCM Console on the CAS will have to manually reset the connection to point to the Primary Site Server
    
  • Reporting services on the CAS will be stopped and users pointing to the CAS for accessing SCCM reports will have to point to the primary site server for reporting requirements
    
• Impact for End Users
  
  • No new application packages can be created on the CAS and distributed, though the applications can be created on the Primary Site Server
    
  • New patches can not be synced up with the Microsoft website, though existing patches will be available for all clients
    
  • SCCM based antivirus definitions will not be applied, though these can be applied through a UNC path on another server
    

Impact – Medium

Summary – No new patches and antivirus definitions can be deployed via CAS

 

Impact of Database Outage at Primary Site Server

If the database is down at the Primary Site Server level the following impact will be seen:

• Impact for Administrators:
  
  • SCCM will not be able to store inventory of any new clients
    
  • No new updates from the Secondary Site Server will move up the hierarchy in SCCM
    
  • Discovery Data of clients will not be updated to the database
    
    • Heartbeat discovery will not be updated on the database
      

  
   

• Impact for End Users:
  
  • New deployments of any of the below payloads will not be advertised to the clients:
    
    • Application Updates
      
    • Software
      
    • Antivirus
      
    • Image
      
  • No new application packages can be created on the primary site server, though these applications will not be created on the Primary Site Server by default
    
  • If the Primary Site Server goes down just after installing SCCM on a new client, then
    
    • It will not show up in SCCM
      
    • Any SCCM deployments on that new client will not happen
      
    • New clients will not recive antivirus policies
      
    • New clients will not get patched
      
    • New clients will not get any applications or baseline policies
      

 

Impact – High

Summary – No new patches, antivirus definitions, and packages can be deployed to any client in the environment and no new SCCM clients can be provisioned

 

Impact of Database Outage at Secondary Site Server

If the database is down at the secondary site server level the following impact will be seen:

• Any client updates will not be replicated between the primary and the secondary site server i.e.
  
  • Inventory updates will not flow to the Primary Site Server
    
  • Meta data of packages also called as the site data will not replicate between the primary and secondary site servers
    
• New deployments of any of the below payloads will not be advertised to the clients that are assigned to the secondary site:
  
  • Application Updates
    
  • Software
    
  • Antivirus
    
  • Image
    

  
   

Impact – Medium

Summary – No new patches, antivirus definitions, and packages can be deployed to any client that are local to the secondary site

 

HA/DR Requirements
SCCM leverage SQL replication heavily behind the scenes. Replication is not directly configured in SQL but is configured as a result of changes that are made via the SCCM installer and configuration toolset. Replication will exist between the Central Administration Site Server, the Primary Site Server and a number of secondary site servers located in satellite offices internationally. The replication topology is as follows:

• Central Administration Site Server will replicate with Primary Site Server and vice versa
  
• Secondary Site Server will replicate with Primary Site Server and vice versa