Active Directory Rights Management Services is a very powerful and useful product to use for protecting sensitive and confidential data, however many people are unaware of the capabilities it has. I hope in this post to give a very high level view of what it can do and follow up with some more architectural lower level blogs for those more interested

It is recommended that an RMS install uses a SQL database on a separate machine to store all logging information, Configuration information etc. Once the RMS role is installed on a member server then a SCP (Service Connection Point) is published in AD so that whenever a user tries to protect/consume data using RMS aware applications they know where to go to get certified or licensed for this.

On the client side an RMS Client is required. Operating Systems from Vista onwards include the client in the default installation however for earlier OS’s the client can be downloaded from Microsoft. As RMS is reliant on IIS and is a web based technology the client requires an email address attribute in Active Directory as this is what RMS uses to identify users. This does NOT mean that you need exchange or any kind of email system installed internally.

When a user attempts to consume content for the first time they will receive a machine certificate as well as a Rights Account Certificate to identify them, this will check the publishing licence to see if they have access and what access they have and then send them a use licence based on this. When they first try to protect content they must be connected to the network to receive a Client Licensor Certificate which allows them to publish content, however once they have a CLC they can protect content offline. All these certificates are stored in the users profile in XrML format.

When a user tries to protect content they have two options, they can either set manual permissions, or select from templates that can be created on the Root Cluster. As well as permissions you set conditions, some of these include allowing the ability to print, forward or when you want the content to expire and therefore be inaccessible (Microsoft is currently working towards automatic protection and this is implemented to a degree in SharePoint 2007 and very well in Exchange 2010, will hopefully go into more detail in a later post!)

Currently RMS aware file formats include the Office suite (excluding One Note) and xps although additional IRM protectors can be downloaded from 3rd party sites to support protection for hundreds of file formats, very cool stuff!

See my next post for more information on the RMS Certificates.

I have a SCCM server installed on site to deal with client and server machine patching. After the last patch Tuesday I noticed that the windows updates under Software Updates had not been synchronized with the latest updates. To dig deeper into this I navigated under System Status – Site Status – <<site name>> -Component Status and noticed that the SMS_WSUS_SYNC_MANAGER component was in a warning state. By right clicking and selected Show Messages – All i was able to see a bit more information:

The entire description is as follows:

SMS WSUS Synchronization failed.

Message: Thread was being aborted.

Source: Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WSyncAction.WSyncAction.SyncUpdates.

Seems strange that the thread was being aborted so I decided to have a look at the good old Application event viewer to see what was going on at a similar time. I found that the SMS_SITE_BACKUP component was running a split second after the SMS_WSUS_SYNC_MANAGER component which was causing the SMS_SITE_VSS_WRITER component to stop the SMS services as part of preparing for backup (wow that’s a lot of components in one sentence!)

I then changed the schedule start after property for this back up component task by navigating to Site Management – <<Site Name>> – Site Settings – Site Maintenance – Tasks – Backup ConfigMgr Site Server Properties and set the Schedule to run at a time that doesn’t conflict with the synchronization (just an hour later than it was).

This solved the issue and updates are synchronizing happily again now

Hopefully this can save you some valuable troubleshooting time!

I recently had to perform the above task and although it has been documented, i thought i would give my view on it and some of the things that seem to be slightly unclear usually.

So you want to migrate DHCP from one server to another (both 2003) maybe for consolidation purposes or to decommission old hardware etc. The first step is to make sure you know the environment, are there multiple subnets, VLAN’s etc, if so chances are you will need to take into consideration the IP helpers for DHCP on the switches (presuming they are layer 3) or routers, these point the DHCP broadcasts in the right direction when looking for an IP address. If these networking points are taken into consideration then the following steps can be followed

1. On the current DHCP server run the following command – netsh dhcp server export C:dhcp.txt all
2. Move the resulting file to the destination server
3. Install DHCP service on the destination server – Start >> Control Panel >> Add or Remove programs >> Add/remove windows components >> Networking services >> DHCP (you may need installation media for this)
4. Log onto the destination server with an account that is an Explicit member of the local Administrators group, it cannot be a user account in a group that is a member of Local Administrators (so if on a domain controller which i was, you will need to restart in DSRM mode and use the administrator account this way)
5. Make sure that the DHCP service is started on the destination server and then run the following command – netsh dhcp server import C:dhcp.txt all making sure that C:dhcp.txt is the full path to where you copied the file locally
6. After receiving the message that the command completed successfully exit the command prompt.

Using this method of the netsh command migrates the DHCP configuration as well as the current lease configuration which prevents conflicting IP addresses

You finally must authorize the new DHCP server in AD, This must be done using an account that is a member of the Enterprise administrators group (So if on a DC you will need to reboot normally again to log on with a domain account to do this). You can do this in the DHCP console by Right clicking the server name and selecting Authorize. You should then be able to stop and disable the DHCP server service on the old DHCP server and receive DHCP addresses from the new one!

Note – If on a DC and you cannot remember or do not have the DSRM password documented you can change it easily from the Command Prompt on the DC by:

• Start >> Run >> ntdsutil >> Ok
• Type Set dsrm password null and press Enter
• Type Reset password on server null and press enter
• enter and confirm the new password

null indicates it is the local server you are changing this password on, if it was on a remote server you wanted to change the password then you would replace ‘null’ with the server name e.g. ‘set dsrm password server1’

I recently came across an issue on customer site where backup to tape jobs were failing because the tapes inserted were showing up in the DPM console as “Suspect Tape”. The reason for this is actually to do with the way DPM identifies the tapes.

A suspect tape is when a tape or tapes have conflicting identification information. If your tape library has a barcode scanner then check that no two tapes have the same barcode if they do you will need to assign one of the tapes a different barcode. Also there can be conflictions with the on-media identifier (OMID) which is written to the start of each tape and is read before using the tape.

To resolve this issue of conflicting OMID’s firstly remove the suspect tapes from the library, then rescan and inventory the library. After this we need to run the ResolveSuspectMedia.cmd script. This can usually be found in %SystemDrive%program filesMicrosoft DPMDPMbin, if not you can enter the following in a text editor and save as ResolveSuspectMedia.cmd:

osql -E -S localhostMS$DPM2007$ -d DPMDB -Q "UPDATE tbl_MM_ArchiveMedia SET IsSuspect = 0"

Finally enter the tapes back into the library and inventory and hey presto you should now be able to use the tapes to perform successful tape backups!

The above error message can be seen when trying to connect to a virtual machine from the Hyper-V console on the Hyper-V host.

The reason for this is that the self signed Hyper-V machine management service certificate has expired, this is the certificate issued to itself for authentication when Hyper-V role is installed on the server.

The workaround for this is to: Shut down all VM’s, restart the Hyper-V VMMS, start the virtual machines again. This renews the self signed certificate for another year. However a better resolution is to install the following handy-dandy, super duper Microsoft KB! By doing so this will in the future auto-magically update the Hyper-V VMMS certificate………

KB967902

Hope this helps!