Online OCS Custom Presence Tool

To stop the query returning duplicates, just change it to ’select distinct a.UserAtHost …’

Also, can extend the query slightly to provide a bit more info such as:

Declare @FrontEndServerID int
Set @FrontEndServerID=2

Select Fqdn "FE-Server-Name" from rtcdyn.dbo.FrontEnd where FrontEndId=@FrontEndServerID

Select count(distinct a.UserAtHost) "Active-Users-Count" from rtc.dbo.Resource a,
rtcdyn.dbo.DeliveryContext b where a.ResourceId=b.SubscriberId and b.FrontEndId=@FrontEndServerID

Select distinct a.UserAtHost "Active-Users" from rtc.dbo.Resource a,
rtcdyn.dbo.DeliveryContext b where a.ResourceId=b.SubscriberId and b.FrontEndId=@FrontEndServerID order by a.UserAtHost asc

Checked in the vCenter database for details on the plug-ins available. The table in question is [VPX_EXT_CLIENT], the field [EXT_ID] will tell you which plug-in each row refers to. In this case it is the com.vmware.converter row. Noticed that the [URL] field had spaces in it (the field read: http://:80/vmc/VMware Converter Client.exe). Changed the spaces to %20 (since this is a HTTP service) so the field read: http://:80/vmc/VMware%20Converter%20Client.exe), retried the download from vSpher Client, all worked well.

I figure the plug-in’s details were updated in the database when the Converter service was installed on the new vCenter service but not sure why it ended up like that. So, put the database entry back to it’s original format (i.e. spaces instead of %20’s) and went to another client that did not have the Converter plug-in installed. Interestingly, it could see the correct name and description and could download and install the plug-in…

This SRM implementation was using EMC RecoverPoint. To get the RecoverPoint SRA installed, SRM had to already be installed. However, couldn’t install SRM because it’s services would not start since the existing database it was connecting to expected the SRA to be available. Resolution was along the lines of the following:

*Make sure you have a backup copy of the database or use a temporary database (I used backup/restore method as opposed to a temp DB)*

1. Make sure the Site Recovery Manager Server service on the old server is stopped.
2. Backup the known good copy of the database
3. Run the SRM installer on the new 64-bit server, when prompted select the DSN (you created a 32-bit DSN, right?) to the existing database (choose to maintain the contents / do not overwrite)
4. Complete the installer
5. This is where it got funky. The Site Recovery Manager Server service fails to start so checked the logs located at %ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Site Recovery Manager\Logs (open the current .log file)
6. The prompt at the installer will have the Retry and Cancel options. If you choose Cancel it will rollback the install and leave the database in an unhealthy state – this is where our backup is going to come in handy.
7. Once the rollback completes, start the install again and complete the exact same steps (this time it will not prompt you about overwriting the existing database as it doesn’t believe the database has vaild data). Allow the install to go through – it will finish this successfully this time.
8. Now, install the EMC RecoverPoint SRA. It will install successfully since SRM is now installed.
9. Uninstall SRM (just step through the uninstaller, don’t check the box about removing the database contents – not that it will matter as we will be restoring our known good copy anyway).
10. Restore the backup of the database choosing to overwrite the database.
11. Install SRM and this time it will prompt regarding the existing database – select to use the existing database.
12. The installer will still fail this time as well, but checked the log this time and found the following:

[2010-08-26 15:34:40.560 03192 verbose 'PrimarySanProvider'] Loading Array Manager 'array-manager-4353' from DB object
[2010-08-26 15:34:40.560 03192 warning 'DrServiceInstance'] Initializing service content: (dr.san.fault.ManagementSystemNotFound) {
   dynamicType = ,
   faultCause = (vmodl.MethodFault) null,
   name = "C:/Program Files/VMware/VMware vCenter Site Recovery Manager/scripts/SAN/array-type-recoverpoint",
   msg = "",
}
[2010-08-26 15:34:40.560 03192 error 'App'] Application error: dr.san.fault.ManagementSystemNotFound. Shutting down ...
[2010-08-26 15:34:40.560 01788 info 'App'] [serviceWin32,421] vmware-dr service stopped

13. The problem here is that the old server was 32-bit windows and therefore installed everything to C:\Program Files\… but our new server is 64-bit and SRM installs to C:\Program Files (x86)\…
14. The array manager script path is actually stored in the database. Find the table [pds_arraymanagere] and update the field [scriptpath] to reflect the correct (x86) directory.
15. Hit Retry and the service should start correctly.

Still needed to re-pair the sites in SRM but this was the biggest hurdle in migrating the server. Also, reading that process back, the whole thing could have been done in a few different ways.Anyway, this was a bit of a worst case scenario but ultimately it worked out well.
Note: This KB article does exist, bubt it is for two specific scenarios as hihlighted in the article, not this situation

Make sure you have the latest / up-to-date versions of Device.xml & Vendor.xml on your BES (will fix “Device not supported” issues). See here [blackberry.com] for current XML files for BES 4.x and 5.x