OCS Create Pool Wizard Error: Invalid database parameter

Recently I had a project where we were moving the OCS databases to a new clustered SQL 2008 (R1) with SP2 Back-End and ran into a lovely new error I'd never seen before - also not seen before anywhere on Google!

For starters, we followed the steps outlined on Technet. After we had successfully detached and attached all databases and ran the LCSCMD.exe step, we launched the Create Pool wizard and attempted to plug in the info for the new SQL cluster. We got this error back:

An error occurred during the pool backend detection:

Pool backend discovery failed.

Invalid database parameter.

I double-checked the server name, instance, and FQDN and all looked well. We verified the SQL server was accessible via TCP 1433 and no firewall rules were preventing access, so the error didn't make a lot of sense. Obviously there was some kind of parameter that the wizard GUI was not cool with. I thought maybe this was the SQL allow updates issue, but that solution had no effect on this error. There was definitely some validation check the UI was failing on against our new DB.

Since I couldn't locate anyone else with this issue I figured my options were to call PSS and extend this process by a few hours, or pull out the ol' LCSCMD.exe again and try this operation via command line. The Create Pool wizard really is just collecting a bunch of information and then using it to execute the LCSCMD.exe commands in the background so while doing it manually is not fun, it works just as well.

The entire syntax for LCSCMD.exe can be found on Techet, but here is the command we ended up running. Please note, conferencing archiving was not implemented so that paramter is not present.

LCSCMD.exe /Forest /Action:CreatePool /PoolName:MyOCSPool /PoolBE:MySQLServer.ptown.local\OCSInstance /PoolFQDN:MyOCSPool.ptown.local /InternalWebFQDN:MyOCSPool.ptown.local /ExternalWebFQDN:PublicOCSWebComponents.confusedamused.com /RefDomain:ptown.local /ABOutputlocation:\\\\MyFileServer\AddressBook /MeetingContentPath:\\\\MyFileServer\MeetingContent /MeetingMetaPath:\\\\MyFileServer\MeetingMetadata /AppDataLocation:\\\\MyFileServer\AppData /ClientUpdateLocation:\\\\MyFilerServer\ClientUpdates /DBDataPath:"D:\Databases" /DBLogPath:"L:\Logs" /DynDataPath:"D:\Databases" /DynLogPath:"L:\Logs" /ABSDataPath:"D:\Databases" /ABSLogPath:"L:\Logs" /ACDDataPath:"D:\Databases" /ACDLogPath:"L:\Logs"

After running the command manually it succeeded with absolutely no issues. The new cluster has been running for over a week now without any issues so I think this is an problem specific to the UI. I'm not sure exactly what causes it, but our environment was running SQL 2008 with SP2 on top of a 2008 R2 SP1 operating system.

As a sidenote, this process seems to undo any changes made by the OCS2009-DBUpgrade.msi patches. You'll need to re-run the patch version which lines up with your FE patch levels before the FE services will be able to start.

OCS Create Pool Step Failure Drops Conference Directories

Something to keep in mind before you ever move an OCS database is that you'll want to grab backups of the user data and conference directories so that you can restore the data just in case anything goes wrong with your move operation. The conference directory objects map conference IDs and passcodes used by PSTN dial-in users to a specific Live Meeting instance. These objects are stored in Active Directory and not in the OCS back-end database like you might expect, but you can still back up all the data these objects hold.

You can export all user data and conference directories with the following command:

dbimpexp.exe /hrxmlfile:everything.xml /sqlserver:SQL.ptown.local\OCS

I usually also grab a separate backup of just the conference directories from the pool:

dbimpexp.exe /hrxmlfile:confdirs.xml /sqlserver:SQL.ptown.local\OCS /restype:confdir

After these run successfully you can copy these files off to a safe place and then proceed with your database operations.

As you are moving the databases around one of the steps on Technet will have you re-run the Create Pool wizard, but if this step fails for any reason the installer will kick into its rollback mode and remove any configuration changes it made. What's not terribly apparent is that part of this rollback process removes all conference directories on the pool without any warning.

So say this step fails on something silly like a file share permission you'll suddenly find you dropped all your conference directories. The end result of that is users calling in to meetings via PSTN will no longer be able to enter conference ID and passcode to join the meetings hosted on that pool.

I recently ran a DB move and the user account we used did not explicityly have Full Access rights to one of the OCS file shares (it had been removed at some point for an unknown reason), but the result was the Create Pool operation kicked into rollback mode and removed the pool's conference directories. We had a solid backup of these to restore from, but this customer had previously lost the directory the first time they tried this operation on their own because of the same problem.

If the directories are dropped and you don't have a backup via DBImpExp.exe you'll need to recreate the conference directories on the admin side, but the big pain point is that all users will need to reschedule their meetings (because the previous ID/Passcode mappings are no longer valid). It's a really ugly user experience and likely to not go over very well. If only you had backed these up in advance!

I would imagine you could restore the conference directory object stored in AD and possibly get that hooked back up to OCS, but your best bet is really to be using DbImpExp.exe instead. A general best practice for any OCS environment is to be taking regular backups of your OCS data and conference directories via DbImpExp.exe so that way you'll never find yourself in this situation.

If your Create Pool step does fail at least one time you'll need to restore the directories because they've been dumped. After you work out the Create Pool step issue and succeed in starting up your Front-End services you can proceed with the conference diretory restore.

The syntax to restore just the conference directories from the pool is:

dbimpexp.exe /import /hrxmlfile:confdirs.xml /sqlserver:SQL.ptown.local\OCS /restype:confdir

After running this you should be able to dial in via PSTN and enter a conference ID and passcode from a pre-existing meeting again.