Just a quick post showing how to change the certification pipeline to use SSL after initial install not choosing to secure the URL. This may be the case if you need to request a certificate after initial set up or are waiting on a third party certificate, or just change your mind! The steps to do this are outlined below:

1. Open IIS on the AD RMS server and edit the bindings, add a binding for HTTPS selecting the certificate to use making sure the name matches your cluster URL.

2. Remove the HTTP binding from the list and do an IIRESET.

3. Close and reopen the AD RMS console and ensure in the centre console both URL’s are using HTTPS.

4. If the SCP has already been published in Active Directory you will need to re-publish it so that clients discover the new HTTP’s certification pipeline.

Good Luck!

Ash

When deploying the FIM Portal the page is built on WSS 3.0. You may notice that after deploying the Portal you are just displayed by the default WSS 3.0 page when browsing locally or remotely.

When you deploy the FIM Service and FIM Portal it actually installs two .wsp’s which style the SharePoint site in accordance to the FIM Portal functionality. Sometimes after initial installation these features are not enabled by default. To enable them navigate to Central Administration > Site Actions > Site Settings > Site Features and select Activate on both ILM2 Pages and FIM Password Reset Pages

You should then be able to navigate to the url locally and remotely and see the normal FIM Portal page

Hope this helps some headaches as there arent too many pointers as to why this happens

Thanks,

Ash

After installing numerous Windows Updates, usually when bringing a newly installed server up to date on patches, you may recieve the following error in server manager:

Error: Unexpected error refreshing Server Manager: Exception from HRESULT:0x800F0818d

This issue occurs when corrupt .mum or .cat files are present after the extraction and installation process of windows updates.

To reolve this we need to complete a few steps

1. Download and run the Microsoft Update Readiness Tool from http://support.microsoft.com/kb/947821 once it has run check the log in C:WindowsServicingPackagesCheckSUR.log

2. You should see errors resembling:
CBS MUM Corrupt 0×00000000 servicingPackagesPackage_for_KB978601~31bf3856ad364e35~amd64~~6.0.1.0.mum Expected file name Package_for_KB978601_server~31bf3856ad364e35~amd64~~6.0.1.0.mum does not match the actual file name

and further down

Unavailable repair files:
servicingpackagesPackage_for_KB978601~31bf3856ad364e35~amd64~~6.0.1.0.mum

3. There may be more than one problematic update so make a note of all of them, you will then need to download these KB’s and unpack them using the following commands:

Expand -F:* UpdateKB978601.msu C:Directory

This then shows a cat file which also needs to be unpacked:

Expand -F:* UpdateKB978601.CAB C:DirectoryCAB

4. You will need to grab the two files, one extension .mum and one extension .cat, then rename them making sure they are exactly as was displayed in the CheckSUR.log file. You will then need to copy them into the C:WindowsServicingPackages directory overwriting the existing ones.

These steps should resolve the issues and you should be able to add/remove Roles and Features again

Sometimes after delegating permissions to a user or group it may be required to revoke them (maybe the user has left or group belongs to a temporary team of contractors). To do this you cant go through the delegate control wizard and take back the permissions as you would expect so just thought i would put a quick post up showing how to

First of all open ADUC and select view and make sure Advanced Features is checked

Next right click the OU that you need to remove the delegated permissions from and select properties and then the security tab

Here you should be able to see the user/group that you originally delegated permission to. In order to revoke these delegated permissions simply remove them from the ACL

HTH

Ash

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…