Upgrading SRM from 5.0 to 5.5

If you’re one of those shops that skipped over 5.1, and are now catching up and going to 5.5, you will run into problems with your SRM upgrade.  Here’s how to fix them.

After you perform the upgrade, per the VMware Site Recovery Manager Installation Guide, you may run into permissions issues when launching the SRM plugin.

The error message is: Connection Error: Lost connection to SRM Server x.x.x.x:8095  –  Permission to perform this operation was denied.

image

To fix this, you’ll have to go into the database, and do some editing.

First, stop the VMware Site Recovery Manager service.

Connect to the SRM database server.  If you’re not using SQL, adjust these procedures accordingly.  This is SQL specific.

First, make sure you BACKUP your database.

Under your SRM Database, you’ll see a table called dbo.pd_acedata. Right click that table, and Select Top 1000 rows.

image

In your Results window, you’ll see that the only permissions that exist are old school pre-SSO “Administrators”.  We need to fix that.

To fix it, we’re going to delete that row. Right click the table again, and select Edit Top 200 Rows.

image

Now, select that row with the old Administrators permission, and right click to delete it.

image

Click yes.

image

Now we have to do the same thing to the dbo.pd_authorization table. Edit the first 200 rows.

image

Delete the first line that says DR_ACEData, and click yes again.

Now go start the SRM service.  This will automatically populate your database with the new permissions you’ll need to launch the SRM plugin, and connect. 

If you go back to the table, you can see it has the correct permissions.

image

For some reason, this is a known issue, but the KB is not public.  So here’s your KB.

Don’t forget to backup your database, so you can restore if you blow it up.  Happy upgrading.

2 comments Add yours
  1. A solution that worked for me was to login to vCenter with an account that is part of
    “Administrators” group that you see in the dbo.pd_acedata table. That
    group is actually the local Administrators group on the local server itself –
    it’s not the Administrators group of domain (which will show up as
    CONTOSOAdministrators) or part of vCenter SSO. So, I logged in as a local
    server user that was part of that Administrators group (in my case it was a renamed
    account from the original Administrator account) and was able to load SRM
    plugin. From there I went to permissions tab and added the domain group that
    should have correct permissions and was then able to login SRM with a domain
    user that was part of that domain group as expected. If you are able to fix it this
    way, you don’t need to fumble with SQL entries.

Leave a Reply

Your email address will not be published. Required fields are marked *