Quite a few weeks ago now I came across this issue on a customer site and managed to resolve narrowing it down to group policy and finding the troublesome policy to be the setting for "Access this computer from the network". On Monday of this week Microsoft released a KB article detailing this problem (http://support.microsoft.com/kb/2663354) but thought it was worth blogging as i did come across it a few weeks ago (promise!)

Basically when you modify this particular group policy setting it changes the local policy on the machine. Manage out capabilities in Direct Access require the internal source user and computer account to authenticate IPsec connections to the DA client. This particular policy setting controls what accounts have access to system services on the DA computer. If the source computer account does not have this access then IPsec authentication will fail. The default setting for this is the only supported one currently for DA, by default this includes – Administrators, Backup Operators, Everyone, Users

Hope this helps others resolve a peculiar difficult to determine issue!

Ash

I recently had this problem on a customer site, documents could be protected using RMS with manual permissions no problems, bootstrapping process completed and all was fine. However after creating Administrative Templates and attempted to apply protection using those templates it failed with the useful “An unexpected error has occurred..” message. Hmmm head scratcher…

So troubleshooting I made sure i had applied permissions correctly on the template, not that i should receive an error message like the one i was getting but good place to start. Checked access to the template file share, fine. Checked AD RMS server was exporting the templates correctly, fine but I did notice something else in checking this ..

I opened one of the templates in an XML editor and noticed that the licensing cluster URL contained a :443, then checking in the AD RMS console this was the case in the licensing URL there too. The trouble with this is that the CLC certificates are attempted to be matched with the RAC’s using the RMS URL, if they are different (certification has no :443 and licensing has :443) you hit an error.

To resolve this issue follow these steps (Note: While following these steps you will remove the SCP temporarily, users will not be able to protect or consume new content during this period so be careful!):

1.)  Open the ADRMS  console and Right Click on the Server name, and go to Properties.

2.) Go to the ‘SCP’ tab and remove the SCP.

3.) Go to the Cluster URLs tab, and check the box for ‘Extranet URLs’ (If you have Extranet URL’s configured then ensure the :443 is not present and move on)

4.) Enter anything into both boxes and click Apply.

5.) Uncheck the ‘Extranet URLs’ box, and hit Apply, then OK.

6.) Close the ADRMS Console and re-open it.

7.) Right Click on the server name>Properties>SCP Tab, and register the SCP.

8.)Check your RMS settings now and make sure that no :443 exists in any of the cluster URLs.

9.) Go to Regedit and create this key on each cluster in the server

HKLM/Software/Microsoft/DRMS

Reg_Sz:GICURL
Value: https://adrms.yourdomain.com/_wmcs/certification/certification.asmx

11.) Go to an Administrative command prompt and run IISRESET on each server in the cluster

12.) Go to client PC and delete the %localappdata%\Microsoft\DRM folder.

13.) In the ADRMS console right click the Administrative Template and select “Archive this Rights Policy Template”

14.) Select Manage Archived Rights Policy Templates and Right click the template and select Copy, give it a different name

15.)Right click the copy and select “Distribute this Rights Policy Template”

Once these steps are completed you should be able to go back into your application and apply protection using the Administrative Template! Yay!

HTH

Ash

Just wanted to create a quick post to share an issue i had recently while on a customer site installing an AD RMS High Availability solution.

The solution had two AD RMS servers using a HLB for redundancy, both servers were installed and joined to the same RMS cluster with no problems. However when the HLB was introduced we couldn’t protect content. Also we couldn’t reach the certification cluster URL (https://ADRMS.yourdomain.com/_wmcs/certification/certification.asmx) IE would just time out eventually.

To cut a long story short after checking all the usual things such as SCP, connectivity, Load Balancer config, DNS etc. it turns out that AD RMS doesn’t like cookie encryption on the HLB! Once we disabled cookie encryption clients were getting load balanced as expected and able to protect content

(note: This particular HLB was F5 BIG-IP)

Ash

I was recently on a customer site and had configured the Synchronization Service including creating Management Agents, projections, joins etc. I then realised i had not installed update 2 for FIM, so i proceeded to download and install the update through windows update only to be met with the following error:

Error 25070.Error connecting to database FIMSynchronizationService. Invalid class string

Doh! Silly me, with the databases homed on a remote SQL server the SQL Native Client must be installed on the FIM server. I had forgotten to do this, after doing so the update completed without issue

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