User Orchestrator with Service Manager to Disable User Accounts – Part 3

14 Oct

In Post 1 I showed you how to create a runbook to disable a user account with the only input being the Activity Guid of the runbook in Service Manager. In Post 2 I showed you how to create a new management pack and class in the Authoring Tool. In this post we will create a runbook template in Service Manager 2012 using the runbook from Post 1 and then create a Service Request template based on the custom class from Post 2 containing the new runbook activity template.

  1. If you have configured the Orchestrator connector in Service Manager 2012 then after a synchronization you should see the runbook create from Post 1. Go to Library and then Runbooks to see all runbooks that have been imported.

  2. Click on the DisableUser runbook and then in the Tasks pane click on Create Runbook Automation Activity.
  3. In the next window give your template a descriptive name such as Disable User Runbook Template, leave the class as Runbook Automation Activity and choose the management pack that was created in Post 2. Click OK.

  4. Next the template will pop up. Give it a descriptive title, choose an Area such as Directory\Account Management and a State such as Release. Also it is very important to check the “Is Ready For Automation” checkbox as this will allow the runbook to run automatically without an administrator needing to manually check the box later.

  5. Next click the Runbook tab at the top. You can either edit the mapping for the ActiveGuid on this template or on the Service Request template later. I will go ahead and map it here by clicking Edit Mapping, expand Object and click ID. I cannot map the PortalUser mapping here because it depend on data from the Service Request. Therefore it will be mapped later in the Service Request Template.

  6. Click Close and then OK. At this point your runbook template is complete.
  7. Next we need to create the Service Request template. In the Library section go to Template and click Create Template. Give the template a name such as Disable User Service Request Template. Choose the class from Post 2, when you browse for this class you will need to change the filter to All Basic Classes in order to see the custom class. Be sure to save the template in the new management pack created in Post 2

  8. Next, fill out the fields on the General tab of the template the way you want then to be when new service requests of this class are created.

  9. Next click the Activities tab and add a new activity. Choose the template created earlier in this post. This will bring up the template as shown below.

  10. Click on the Runbook tab of the template. You can now map the PortalUser property mapping because the DisableUserClass is now available to map to. Be sure to map this property to whatever field that you are going to map it to later when creating the request offering. For example, later I will map the portal user to the Notes field of the Service Request so as shown below, I will also map the runbook property to the Notes field of the DisableUserClass.

  11. Click Close and then click OK twice to complete the creation of the template.

In the next post we will create a request offering based off of this service request template. We can then add the request offering to a service offering and publish both to the portal.

Use Orchestrator with Service Manager to Disable User Accounts – Part 2

14 Oct

In the previous post I showed you how to create the Orchestrator runbook that actually does the disabling of the user account. In this post I will show you how to use the Service Manager Authoring Tool to create a custom class based off the Service Request class that we will use in Service Manager later to build the templates. Remember that this step is optional as you do not need to have a custom class and could use the default service request class. The reason I like to use custom classes is because a lot of times you are capturing more input from the user than the default service request class has fields to put that info. With a custom class you can create as many properties as you want and name the properties according to the input capture.

  1. Open the Service Manager 2012 Authoring Tool. If you do not have the Authoring Tool yet it can be downloaded from here. http://www.microsoft.com/en-us/download/details.aspx?id=28726
  2. Create a new Management Pack and call it something that describes the new class that you are going to be creating. For instance I will call mine Disable.User.xml.

  3. Next you need to create a new class. Right click on Classes and click Create other class…

  4. Search for the Service Request class and then click OK.

  5. Give you new class a descriptive name. For instance I will call mine DisableUserClass. Click Create.

  6. By default a new property will be created called Property_35. Scroll to the bottom of the properties and delete this new property.

  7. If you needed custom properties in your new class then you could easily create them here using the Create Property button. You can create several types of properties including strings, DateTime, lists, etc. In this case we do not need any new custom properties because the only input we will require from the user will be a selection of the AD user account to disable. Click Save and to save the management pack. Go back to the Service Manager console and Import the management pack into Service Manager.

     

    In the next post we will create a runbook template based off the runbook created in Post 1.

MCSE: Private Cloud Certification – I’ll take one!

21 Sep

Well, today I went and took the 70-247 “Configuring and Deploying a Private Cloud With System Center 2012” exam today which was all that I had left to earn the new “MCSE for Private Cloud” certification that Microsoft started offering this year.  When the whole “cloud” buzz word started I didn’t buy the hype and just thought it was a marketing term.  Although I still think it gets thrown around WAY in too much in advertising I do see where Microsoft is going with it and I do think the concept of all servers being virtual except for of course the physical hosts is the future, so a better way to manage that kind of infrastructure is definitely necessary.

Logistically getting this MCSE was a little more difficult for me then it could have been because Tulsa no longer has a Prometric testing center that offers the exams.  So a trip to Oklahoma City and two trips to Fort Smith,  Arkansas and I finally got it.

That being said, here is a summary of the new certification:

1. MCSA for Server 2008 or MCSA for Server 2012 – 3 exams covering Active Directory, Networking and Administration of Windows Server.

2. Exam 70-246 “Monitoring and Operating a Private Cloud with System Center 2012” – This exam had a lot of Operations Manager 2012 questions which makes sense since the basic premise of the exam covers monitoring.  There was also quite a few questions regarding SLAs in Service Manager and backing up using Data Protection Manager.  There was not a lot of Configuration Manager questions on the exams but there were some questions around keeping systems updated using the new Virtual Machine Manager integration into WSUS. In my opinion this was the harder exam of the two.

3. Exam 70-247 “Configuring and Deploying a Private Cloud With System Center 2012” – This exam was A LOT of Virtual Machine Manager 2012.  I have got to play with VMM 2012 in a lab but I have not had a chance to work with Virtual Machine Manager 2012 a lot since so far no customers have wanted it in their environments. Luckily I found a really good book that covers the product inside and out and reading that book helped tremendously on the exam. Let me point out that I am in no way associated with this book but I definitely recommend it. It’s called “Microsoft Private Cloud Computing” and can be found on Amazon for about $30.  http://www.amazon.com/Microsoft-Private-Cloud-Computing-Aidan/dp/1118251474 In addition to VMM there was also quite a bit of Service Manager and very little SCOM, SCCM or DPM.

PKI Infrastructure – Two Tiered Setup with Offline Root CA

19 Sep

I have been having to setup a lot of PKI infrastructures lately, sometimes related to the fact that customers want to use Internet Based Client Management in SCCM but dont have the PKI infrastructure to support it. There is a lot of good writeups on the web about setting these up but I made up my own doc that I use to set these things up in under an hour.

Install Root CA

  1. Build a new stand-alone root CA, not attached to domain, this server can have Server 2008 Standard Edition.
  2. Log on to the server as the administrator and install Certificate Services to create a stand-alone root certification authority.
  3. Install Certificate Authority service only, IIS is not needed.
  4. Create a new private key
  5. Ensure the common name for the CA is unique.
  6. Change the validity period for the CA’s certificate to 10 years.

Install Sub CA
Build new enterprise subordinate CA and add to domain. The OS on this server must be Server 2008 R2 Enterprise or Datacenter Edition.

Add the following role services
Certification Authority
Certification Authority Web Enrollment
Online Responder

Setup type is Enterprise, Subordinate CA, create a new key, Cryptographic service provider (CSP): RSA#Microsoft software Key Storage Provider
Key length: 2048, Hash algorithm SHA1. Certificate Request: Save a certificate to file and manually send it later. Server Authentication Certificate: Choose and assign a certificate for SSL later.

Save the certificate request to a file and manually copy it to the parent CA.
Save this file to the C drive, and copy to the C drive of the root CA.

We need to setup a CRL for the new offline Root CA and change the URL location of the certificate revocation list (CRL) distribution point to a location that is accessible to all users the network while the Root CA is offline. This is needed because the offline root CA’s default CRL Distribution Points (CDPs) are not accessible to users on the network and, if they are left unchanged, certificate revocation checking will fail.

On the Root CA, Open Certification Authority

Right click on the RootCA server name -> Properties -> -> Extensions tab -> extension type: CRL Distribution Point (CDP):

Mark the line begins with “LDAP”, and click ‘Include in the CDP extension of issued certificates’.

Make sure only the following boxes are checked:
1. Include in all CRLs. Specifies where to publish in Active Directory when publishing manually.
2. Include in the CDP extension of issues certificates.

Mark the line begins with “HTTP”, and click remove.

Mark the line begins with “file”, and click remove.

Click on Add -> on the location, put:

http://subcaservername/CertEnroll/<caname&gt; (continued on next line)

<crlnamesuffix><DeltaCRLAllowed>.crl

Tick the following:
1. Include in CRLs. Clients use this to find Delta CRL locations.
2. Include in the CDP extensions of issued certificates

Click on the line begins with “C:\Windows”, and make sure the only options checked are:
1. Publish CRLs to this location
2. Publish Delta CRLs to this location

Setup AIA information for the Offline Root CA, On the Extensions tab -> extension type: Authority Information Access (AIA):
Mark the line begins with “LDAP”, and tick the following box:
1. Include in the AIA extension of issues certificates

Mark the line begins with “HTTP”, and click remove.

Mark the line begins with “file”, and click remove.

Click on Add -> on the location, put:

http://subcaservername/ CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt .

Tick the following boxes:
1. Include in the AIA extension of issues certificates

Click OK and allow the CA server to restart its service

From the “Certification Authority” left pane, right click on “Revoked certificates”-> Properties:

CRL publication interval: 6 months

Make sure “Publish Delta CRLs” is not checked
Click OK

Setup the root CA to issue certificates with an expiry date of 10 years (will issue to the Sub CA for 10 years)
Run from the command prompt – certutil -setreg CA\ValidityPeriodUnits 10 & certutil -setreg CA\ValidityPeriod “Years”
Configure the offline root CA to support certificate revocation listing with Active Directory

On the Root CA, Log on to the system as a Certification Authority Administrator.

Open Command Prompt.

Type the following, and then press ENTER. – certutil -setreg ca\DSConfigDN “CN=Configuration,DC=contoso,DC=com” (replace with your own domain info)

Type the following, and then press ENTER. – certutil -setreg ca\DSDomainDN “DC=contoso,DC=com” ” (replace with your own domain info)

At the command prompt type net stop certsvc

At the command prompt type net start certsvc

From the “Certification Authority” left pane, right click on “Revoked certificates”-> All tasks -> Publish -> click OK

Manual steps to publish the Root CA CRL & AIA

Copy the CRL & CRT file to the Sub CA

On the Root CA, copy the files from C:\Windows\System32\CertSrv\CertEnroll to the same location on the Sub CA

Publish the CRL & Root CA certificate to Active Directory
For this to work, you need to be a member of the Enterprise Admins group. Information is published to CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com ” (except its your own domain info)

From the Sub CA, the two files you copied before (.CRT and .CRL need to be used for this)

Publish the Root certificate to AD – certutil -dspublish -f RootCACertificateFile.crt RootCA

Publish the CRL information to Active Directory – certutil –dspublish -f CACRLFile.crl

Issue the Sub CA a certificate from the Root CA server.

Right click on the RootCA server name -> All Tasks -> Submit new request -> locate the subordinate CA request file (.req) -> Open.
Expand the RootCA server name -> right click on “Pending Requests” -> locate the subordinate CA request ID according to the date -> right click on the request -> All Tasks -> Issue.

From the left pane, click on “Issued Certificates” -> locate the subordinate CA request ID –> double click on the request –> Click the details TAB –> Copy to file – Rootca.p7b -> click Save.

As an option only, on the SubCA, run the command below from command line to avoid offline CRL errors: Certutil.exe -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

On the Sub CA, from command prompt, run – gpupdate/force

Right click on the subordinate CA server name -> All Tasks -> “Install CA Certificate” -> locate the file Rootca.p7b -> click Open.

Right click on the subordinate CA server name -> All Tasks -> Start Service.

Start -> Administrative Tools -> Group Policy Management.
From the left pane, expand the forest name -> expand Domains -> expand the relevant domain name -> right click on “Default domain policy” -> Edit.
From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> expand “Public Key Policies” -> right click on “Intermediate Certification Authorities” -> Import -> click Next -> click Browse to locate the CRT file from the subordinate CA server (C:\Windows\System32\certsrv\CertEnroll) -> click Open -> click Next twice -> click Finish -> click OK.

By default, IIS 7.0 request filtering blocks the plus sign (+), which is used in the URL of delta CRLs. To allow delta CRL retrieval, modify the IIS configuration by setting allowDoubleEscaping=true on the requestFiltering element in the system.web section of IIS configuration. For more information about IIS 7.0 request filter configuration, see IIS 7.0: Configure Request Filters in IIS 7.0.

appcmd set config /section:requestfiltering /allowdoubleescaping:true
Appcmd.exe can be found – %windir%\system32\inetsrv

In Certificate Authority, rightclick on the subCA and go to Properties. Go to the Extensions tab, in CDP modify the entry that begins with http and check the boxes as shown:

1. Include in CRLs. Client use this to find Delta CRL locations.
2. Include in the CDP extension of issued certificates

Next go the AIA dropdown, modify the entry that begins with http and check the box:
1. Include in the AIA extension of issues certificates

Start and Stop the Certsvc service.

Setup the Online Responder (This is optional)
Step 1
To advertise that revocation status information for a particular CA can be obtained via OCSP, the CA must include a pointer to the OCSP Responder in the certificate. This is done by adding an OCSP URI to the AIA extension of the certificate. This is a configuration made on the CA and will be applied to certificates issued by the CA.

1. Open the Certification Authority Snap-in on the CA, as an Enterprise Administrator

2. Right click on the CA name, and select Properties

3. Click on the Extension Tab. From the Select Extension drop down Box, select Authority Information Access (AIA). This is shown below. Add an entry for the online responder such as http:// yourwebserver/ocsp

4. Check the Checkbox for Include in the online certificate status protocol (OCSP) extension.

5. Click OK, to close the CA Properties.
Step Two
Configure Enterprise CA with OSCP Signing Template

1. On the Enterprise CA, select Certificate Templates, right click and select Manage. This will open a complete list of the CAs templates in the Certificate Template Console.

2. Locate the OCSP Certificate Template, Right-click, choose Duplicate Template and give it a name specific to your environment.

3. On the Security Tab, add the hostname of the soon to be OCSP Server, and give the server Read and Enroll permissions to the template. Click OK.

4. In the Certification Authority management console, Right-click on the Certificates Templates node, and from the context menu, select New and then “Certificate Template to issue.

5. Select the OCSP Response Signing Template, and select OK.
Step 3
1. Open the Online Responder snapin in Administrative Tools

2. Select Revocation Configuration, right click and select Add Revocation Configuration. A wizard will open.

3. Name the configuration with a friendly name

4. Select a certificate for an existing Enterprise CA

5. Select Browse CA certificate published in Active Directory. Click Browse. You should see your CA certificate so select it and click OK.

6. Next you will need to select a certificate that will be used for signing OCSP responses. For a particular Revocation Configuration, the OCSP Signing certificate must be issued by the CA for which the OCSP Responder will answer revocation status requests. Select Automatically select a signing certificate and select the OCSP template you configured in step two above. Click Next.

7. The OCSP responder will obtain its CRL from the CA so you do not have to add any other provider. Finish the wizard.

Operations Manager 2012 Showing as Eval Edition

19 Sep

I had a customer recently that I installed a new deployment of Operations Manager 2012.  During installation I entered the correct product key but when trying to setup monitoring for network devices an error was generated stating “In order for operations to manager and monitor your network you must complete the following steps: Upgrade to full version”.

The MS article regarding this error can be found here: http://support.microsoft.com/kb/2699998

but here are the steps in a nutshell:

1.       Open PowerShell as an Administrator

2.       Load the OperationsManager Module (import-module operationsmanager)

3.       Connect to your ManagementGroup (New-SCOMManagementGroupConnection)

4.       Use Set-SCOMLicense -ProductId “yourlicensekey“

5.       Reboot Server

Voila, SCOM is now showing as the retail version instead of eval.

Configuration Manager 2012 Gotchas

19 Sep

I have been rolling out a lot of SCCM 2012 deployments lately.  It seems that the addition of Endpoint Protection integrated into SCCM is very enticing to a lot of customers paying someone else for virus protection and pretty much pays for the project in the first year.  That being said here are a few of the common issues I seem to be seeing:

1. BITS 2.5 is not installed on Server 2003 servers – The SCCM client now requires BITS 2.5 as a prereq and it seems that most clients do not have it on their servers.  If they already have a previous version of SCCM then pretty easy to remedy but if not it can be a little tricker.  In a later post I will detail what I have been doing to help the customer get their Server 2003 servers updated.

2. Windows XP SP2 – Another requirement of the SCCM 2012 client is that any XP machine needs to be at Service Pack 3.  Every customer I have visited has had at least some XP SP2 workstations still active on their network.

3. Uninstall passwords for anti-virus agents – The Endpoint Protection agent in SCCM will uninstall some of the more common virus protection agents automatically (Symantec, Trendm McAfee) but most customers have a policy that enforces a password to be entered for uninstallation and if this is still set the Endpoint Protection uninstall/install will fail. Usually this is easily fixed by turning off the uninstall password setting and allowing the clients to get the new policy but when that doesnt work you can easily push registry settings via SCCM to disable the password.  Once that is done the uninstall and following install of Endpoint Protection will complete successfully.

4. Existing WSUS servers in environment – To use the Software Updates features of SCCM you need to install the Update Point role on a WSUS server. The SCCM client will then attempt to set the local policy on the workstation or server to point to this new WSUS server.  The problem is that if there is already a WSUS server and domain level GPOs in the environment pointing to the existing server, these will override what SCCM is trying to set.  When the SCCM client initiates a scan it will fail with an error about a conflicting policy.  There are a few things that can be done here, one is to roll out the SCCM client in a short time period to all workstation and servers and then disable the domain level GPO settings. Be careful that the SCCM client is installed on all systems before disabling the domain level GPO because otherwise the client will have no WSUS settings and may go out to Microsoft and get some updates that you dont want it to have (IE9 for example). The workaround is to set the “Configure Automatic Updates” policy to disabled in a domain level GPO.  With this set the clients cannot go out to Microsoft but all functionality in SCCM still works perfectly.

Use Orchestrator with Service Manager to Disable User Accounts – Part 1

18 Sep

I had a customer recently who wanted a way to allow HR to disable terminated user’s network accounts without having to contact IT.  This was easily accomplished using Orchestrator with Active Directory and Service Manger integration packs along with Service Manager 2012 with the Orchestrator Connector and the SCSM Self-Service Portal.  I will cover this topic in four parts as outlined below:

Part 1 – Create Orchestrator Runbook and syncronize to Service Manager

Part 2 – Create new custom Service Request class with custom propertys (This part is optional as this could easily be accomplished using the default Service Request class instead.)

Part 3 – Create Runbook and Service Request Templates

Part 4 – Create Request Offering and publish to the portal. Optionally create custom View and notification. Part 1 – Creating the Orchestrator Runbook The Orchestrator runbook will look like this when complete:      

1. Create a new runbook in Orchestrator. The first activity should be an Initialize Data activity with a new string property called ActivityGuid. Also if you would like to have the username of the user that submitted the request in the portal readily available for use in Orchestrator (perhaps so that you can send this information to an IT administrator from Orchestrator) then you can also add another string activity called PortalUser.              

2. The second activity will utilize the SC Service Manager 2012 integration pack to access Service Manager and get the User relationship associated to the Runbook activity.  (The Active Directory User we want to get will be selected later in the portal and will be a Configuration Item in the runbook.) From the activities listed  in the SCSM Integration Pack choose the Get Relationship activity and configure as shown:              

If you are not familiar with Orchestrator and subscribing Published Data then you may have trouble with the Object Guid entry shown above but it is very simple. All that you need to do is rightclick in the Object Guid field, select Subscribe and then Published Data. Choose the ActivityGuid property from the Initialize Data activity and click OK. Also make sure the activities have been linked together as you go.  The concept of subscribing to Publish Data will be used throughout this runbook.

3. The next activity will also use the SCSM Integration Pack and the Get Object activity to get the user object associated to the relationship in the previous activity. It should be configured as follows:  

             

At this point you have pulled in all of the Active Directory users associated to the runbook which would include the affected CI Item (the user we want to disable) and the created by user (probably you so definitely a user we don’t want to disable!). To filter out the created by user you need to double click the link between the Get Relationship and Get Object activities, click on Exclude, then Add and add the following:

             

4.  The next activity comes out of the Active Directory integration pack as we will now get the active directory object for the user object that we want to disable. Add the Get User activity and configure it as follows:              

  5. The next step is to actually disable the user account. This is also found in the AD integration pack and should be configured as follows:

     

  6. The last step is optional as you can use the Send Email activity in Orchestrator to send an email to either a single IT administrator or a distribution list that might be concerned with who is disabling users in Active Directory and what users are getting disabled.  To accomplish this we would simply send an email with the body of the email containing the subscribed  published data of the portaluser property found in the InitializeData activity and whatever information that you want to pass regarding the user account that got disabled such as the username of that user.  See screenshot below:            

 

7. Make sure you have the Orchestrator connector properly configured in Service Manager and synchronize it so that the new runbook is brought into SCSM. In Part 3 we will utilize the runbook to create a runbook automation activity.

Travis Marshall