26 Jan 2010

Associate the employeeID attributed with the user class in AD

In preparation for our new HR system, I linked the existing employeeID attributed in our AD Schema to the user class. This allows the storing of employee IDs in Active Directory for each user. A quick guide can be found here

14 Jan 2010

VMware ESX 3.5 and Storage VMotion

We're in the process of expanding the capacity of our production SAN and consequently have to do some shuffling of data between disk groups and LUNs. The first step in the migration was to move the VMs on our production cluster to some newly provisioned LUNs. Initially I envisaged powering down each VM and then selecting to Migrate it and selecting to relocate it's disks as part of the migration process from within the VI client. I didn't fancy this option too much due to the time it would take and the incurred downtime and therefore it would also be more than likely have to be done at a weekend, of which I have very few of as it is.

I'm just cutting my teeth on VMware's PowerCLI so decided to see if I could at least script the process rather than drowning in GUI hell. I found that I could go one better and summon Storage VMotion using PowerCLI. The blurb in the VMware PDF states that;

VMware® Storage VMotion™ enables live migration for running virtual machine disk files from one storage location to another with no downtime or service disruption.

Sounds exactly what i'm after. You have the choice of leveraging Storage VMotion using either an unofficial VI Plugin (not ideal for production), VMware's RemoteCLI or PowerCLI. I mapped out the source and destination LUN's and moved a few VM's at a time by running the following PowerCLI command. While this took sometime to run for each VM, I didn't want to push my luck and was careful of the additonal I/O on the LUN's source LUNs.

Get-VM "VM_Name" | Move-VM -Datastore "New_DataStoreName" -RunAsync

A new task should appear in the VI Client indicating that the VM's storage is being relocated. While this is happening the VM is available and able to function as expected.

13 Jan 2010

Managing Non Domain Integrated DMZ Servers in SCOM 2007 R2

First of all, it's wise to ensure that each of the servers, both the Management and Agent servers have the PKI Certificate chain installed. With an internal PKI such as MS Certificate Services, this can be downloaded from the Certificate Services web interface which is normally http:///certsrv. click the 'Download a CA certificate, certificate chain, or CRL' link, followed by the 'Download CA certificate chain'. A prompt to download the certnew.p7b file which is the certificate chain will appear. The certificate chain should be imported into each Management Server and also DMZ Server as required, using the MMC and Certificates snapin.

To faciliatate the mutual authentication, a new certificate template is required but this will require an Enterprise PKI configured. The MS TechNet article covers the configuration required.

Each SCOM Management Server will require an instance of the newly created OperationsManager Certificate. This can be again be requested from the MS Certiifcate Services Web interface. Navigate to the URL (Normally http:///certsrv) and select 'Request a certificate' and then 'Create and submit a request to this CA.' Select the newly created OperationsManager template from the drop down. It is important that both the 'Name' and 'Friendly Name' fields match the name either FQDN or just NetBIOS of the server. Ensure that that the certificate is installed to the Local Computer Certificate Store on each Management server.

The above step is also required for each DMZ Server which is to host an Agent. It's worth ensuring that the 'Mark keys as exportable' options is checked. This will allow the exporting of the certificate from your local machine to the destined DMZ server. Don't delete the .pfx certificate once imported into the server's local store as it's required for the MOMcertimport.exe step.

Additional steps to ensure that name resolution can take place maybe required depending upon your configuration. Due to my DMZ configuration, I used HOST file entries on the DMZ server with the Management Servers' names and IP addresses and also on the Management servers for the DMZ Servers name's and IP addresses.

In order to install the Agent, I found that MSXML 6 was required followed by the manual GUI install of the Agent. I left all options as standard as part of the install. Once finished, I then ran a second install using the command line which loosely resembled the following. This command defines the Management Group(s) and associated management server as the details cannot be retrieved from Active Directory in this case.

MsiExec.exe /i MOMAgent.msi /norestart /qn MANAGEMENT_GROUP="ManagementGroupName" MANAGEMENT_GROUP_OPERATION=AddConfigGroup MANAGEMENT_SERVER_DNS=ManagermentServer REINSTALL=ALL

In order to import the Operations Manager certificate into SCOM, the MOMcertimport.exe utility is required. While there are many published commands on the Internet, I found the following worked for me. MOMcertimport.exe "Path to the exported Cert with private key"

Once entered you should be prompted for the Private Key password that you previously specified when exporting the certificate to the .pfx format. A successful imported message should appear. You can also check that the certificate was imported correctly by checking the registry on the server. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ChannelCertificateSerialNumber should contain the Serial number of the certificate that you've imported. It's worth restarting the Agent's service to pick up the newly imported certificate.

An 'Run as Account' is required for SCOM, so that it can run tasks on the DMZ based server. This requires a Local account creating which has Administrative rights on the server. The details of the account then need creating in the SCOM Management console. A new Run As account can be created by going to 'Administration' and then under 'Run As configuration', right click Accounts and select 'Create new Run As account'. Set the options as follows in the wizard.

Run As account Type - Action Account
Display Name - Action Account
Username -
Password -
Domain -

Click 'Next' then 'Create' to finish the account configuration.

Lastly the account configuration requires configuring so that SCOM knows to use the new account when communicating with the DMZ based server. This can be done by going to 'Profiles' under Run As Configuration and finding the 'Default Action Account' option. Double click 'Default Action Account' and find the new server in the list. Double click the server and select the newly created 'Run As account' and click 'Save' and 'Close'.

It's probably best to restart the System Center Management service on the DMZ Server so that it can detect the changes made to the SCOM console. That should be it, happy DMZ Management.