When trying to create a new distribution group through EMC you may receive the following error message at the end of the wizard:
Error:
Couldn’t find object "UserAccount". Please make sure that it was spelled correctly or specify a different object. Reason: The recipient UserAccount isn’t the expected type.
Exchange Management Shell command attempted:
new-DistributionGroup -Name ‘test’ -Type ‘Distribution’ –OrganizationalUnit ‘OU’ -SamAccountName ‘test’ -Alias ‘test’
The reason for this is that when creating a Distribution Group it tries to add the mailbox of the user creating it as the manager of the Distribution Group and usually the Admin account that creates the Distribution Groups will not be Mailbox enabled.
To get around this you can use the New-DistributionGroup cmdlet with the ManagedBy Parameter:
new-DistributionGroup -Name ‘test‘ -Type ‘Distribution’ –OrganizationalUnit ‘YourDomain/Distribution Groups’ -SamAccountName ‘test’ -Alias ‘test’ –ManagedBy ‘MailboxEnabledAccount’
Any RMS protected content can only be consumed or created within the trust boundaries of the domain. It is sometimes desirable to be able to share protected content with other external parties (Partners etc) so what do you do then? Well there are a number of options available, of which the main three used are:
TUD – or Trusted User Domain is primarily used when a company with an RMS infrastructure wants to share protected content with another organization with their own RMS infrastructure. In order to do this a traditional Active Directory trust must first be in place, we can then export the SLC public key of the RMS cluster from the domain wanting to consume content and import it on the RMS cluster in the domain wanting to share content. This of course can be replicated both ways so that both sides can open RMS protected content from the other.
TPD – or Trusted Publishing Domain is usually used in one of two scenarios, one where an AD RMS cluster is being decommissioned and replaced. An example might be where forests are being merged and one cluster is taking over the functions of the others. The other scenario might be when a cluster has to issue licenses for content protected by clusters in another forest (can be used for cross forest RMS protected content exchange) To implement this trust you must export the private key of the cluster you are wanting to consolidate and import it into the TPD section of the remaining AD RMS cluster, this is so use licenses can still be acquired for content protected by the decommissioned cluster.
AD FS support for AD RMS – This is an extremely good feature for collaboration with multiple forests where partners do not have their own AD RMS infrastructure or even don’t have directories based on AD. To implement this solution AD FS must be configured and a federation trust must be in place. You then in AD FS usually create a new claims aware application entry for AD RMS certification URL, you can then define which claims to accept (for AD RMS this is UPN then email) you then do the same for the licensing URL. You must also make sure to add the server role for AD RMS Identity Federation Support and enable federated identity support in the AD RMS console. There are some registry key changes that have to be made on the trusted domain machines (the side without AD RMS) so that the home realm discover works correctly but this can be done via GPO’s*. You will then be able to send and receive RMS protected content from this entity even though they do not have AD RMS implemented!
- *Registry Key – HKLM/Software/Microsoft/
- Create registry key: MSDRM
- Under this create another registry key: Federation
- Under this add a string value named: FederationHomeRealm
- with a value of: urn:federation:YourDomain.com
So as you can see there are many options for expanding your RMS protection outside the boundaries of your domain or forest. Hope you find this useful! 
Recently had an issue with our internal RMS infrastructure where users were not able to RMS protect any documents, email etc. Going through some troubleshooting I found that clients were not going through the bootstrapping process correctly and therefore were not getting the needed XrML RMS certificates …..
So I was able to browse to the certification and license pipelines no problems, AD RMS server was contactable, was seeing the traffic hit the server in the IIS logs some with 403 and 404 errors…Resolution??
If you go to internet options >> Advanced >> Security and then uncheck the two options:
Check for the publishers certificate revocation
Check for the server certificate revocation
Then try and RMS protect content then suddenly bootstrapping process works, you get your certificates and all is good!
The reason for this is if your AD RMS certification and licensing pipelines are using an internal CA to issue a certificate for HTTPS and your client machines cant reach the CRL distribution point it will not allow you to connect! The quick fix is to uncheck the two options specified above and go through the bootstrapping process, you will then be able to protect and consume RMS content. However the correct fix is to ensure the CRL distribution is correct for your CA and accessible for your AD RMS clients
Want to implement AD RMS but already have file servers full of unprotected content? No problem! With the AD RMS bulk protection tool and File Classification Infrastructure this can be achieved. In FCI we can create classifications based on business impact (based on Key words e.g. private, or regular expressions such as National Insurance numbers etc) and have RMS templates applied to classifications as we see fit, oh the power! * This can also continue to apply to additional files uploaded to the file servers each time the File Server Resource Manager rules and file management tasks run (which can run on a schedule) You can also using FCI set a flag to apply to files that have been encrypted with a time stamp and can configure it to send an email to the owner of the file which has been encrypted.
Have SharePoint libraries? Again no problem these can be configured to apply protection based on the NTFS permissions on download from the library, it’s all covered! Automation is the new buzz word within RMS and it continues with Exchange 2010’s automatic protection of emails using transport rules to apply pre-defined templates based on email content or recipients.
*Note – By default only the Microsoft Office suite and xps viewer file extensions can be RMS protected, however IRM’s can be downloaded for hundreds of other file types so nearly all file extensions can benefit from RMS protection!
To RMS or not to RMS? I think the former
Just a quick post to advise Microsoft has now released a KB to remove the application manifest expiry feature in AD RMS. The reason for this is that this legacy feature was previously used to confirm that applications accessing or creating RMS protected content were to be trusted.
This was done by applications being signed by application signing certs issued by MS. Once the application signing cert expired the application would no longer be trusted to open or create RMS protected content until it was renewed with application updates, which would cause problems and errors between expiring signing certs and application updates!
This can now be controlled by the system administrator rather than by signing certs, administrators can now define applications, or older versions of applications as untrustworthy themselves.
The update to remove this feature is KB979099 where the update can be found for all RMS client operating systems.
RMS secures data using certificate key pairs, however it does not require PKI which is a common misconception. PKI can be very useful alongside RMS for securing communications between client and server etc however it is not a requirement. The certificates used in RMS are in XrML (Extensible rights Markup Language), those you should be aware of are as follows:
Server Licensor Certificate – This is the certificate created when RMS is installed on the first server in a cluster, it is a unique certificate to identify itself. If further servers are added to the cluster then the SLC is shared with these. By default in a root cluster this deals with certification by issuing RAC’s and licensing protected content. In particularly large implementations additional licensing servers can be installed which have their own SLC
Machine Certificate – This is created the first time that a RMS aware application is used and is tied to the hardware of the machine as well as the user login, so multiple Machine certificates can exist on the same machine if multiple users use it. As well as the machine certificate machines receive a unique Lockbox. The Lockbox contains the machines private key and the machine certificate contains the machines public key so the Lockbox is central to all encryption and decryption.
Rights Account Certificate – This is the certificate which identifies a user and a standard RAC is associated with the computer that the user is logged onto. The SLC issues a RAC to the client the first time they attempt to consume RMS protected content. The RAC contains the key pair and the private key is encrypted by the public key of the machine certificate.
Client Licensor Certificate – The CLC is created by the root cluster and sent the the client when they try to protect content using RMS aware apps. They have to be connected to the network to receive this but it grants them the right to publish content, even when not connected. Same as the RAC the CLC contains a key pair, its private key is encrypted by the public key of the user who requested it (their RAC) It also contains the public key of the cluster which issued the certificate which is signed by the private key of the cluster. The private key of the CLC signs any Publishing Licences it creates
Publishing Licence – The PL is created when a client right protects content and specifies what users have access and what access they have. It contains a symmetric key to decrypt the content which is encrypted by the public key of the cluster which issued the PL.
Use License – This is presented to a client when they attempt to access rights protected content and contains the rights of the authenticated user requesting access. This is tied to the RAC (which identifies the user). The PL will be sent to the Root Cluster along with the users RAC and if access is allowed the cluster will decrypt the symmetric key using its private key and then re-encrypt the symmetric key using the public key of the user. The user will then be able to decrypt and use the rights they have been granted to access the data.
Heavy stuff but hope this can make a little more sense and show how robust AD RMS actually is! Hopefully will follow up with some more information on integration with some well known MS technologies such as Exchange and SharePoint in the near future…
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
- On the current DHCP server run the following command – netsh dhcp server export C:dhcp.txt all
- Move the resulting file to the destination server
- 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)
- 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)
- 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
- 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!
