Wednesday, August 17, 2011

Problems running Get-CSApplicationContact script

You will ONLY see this problem if you started with OCS, then upgrade to OCS R2 and then to Lync.

When looking for your RGS contacts, you may have gone to:
http://blogs.technet.com/b/csps/archive/2011/02/09/scriptrgsrestore.aspx

And ran this script.   Unforunately, when you run it, you may see:

LDAP://CN=Application Contacts,CN=RTC Service,CN=Microsoft,CN=System," + $domainDN
ServiceId of the Registrar service on pool contoso.cpcc.edu = 1-Registrar-1

Corresponding Pool Policy = 1491043820

Exception calling "FindAll" with "0" argument(s): "There is no such object on the server.
"
At C:\\Documents\script\CSApplicationContact\get-CsApplicationContact.ps1:283 char:39
+ $colResults = $objSearcher.FindAll <<<< ()
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException

Contact objects found:

Cannot index into a null array.
At C:\Users\\Documents\script\CSApplicationContact\get-CsApplicationContact.ps1:309 char:69
+ $formattedResult.$propertyName = $objItem.$propertyName[ <<<< 0]
+ CategoryInfo : InvalidOperation: (0:Int32) [], RuntimeException
+ FullyQualifiedErrorId : NullArray
In my case, our instance of Lync was upgraded from OCS, to OCSR2, and then to Lync. 

This was the source of the problem.

Checking the code, right after the "Contact objects found" we see:

$searchPath = "LDAP://CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration," + $domainDN

In my case, we had updated to OCS R2 and Lync without changing the location of where the data was stored in the schema.

$searchPath = "

Changing this one line to point to the correct location of our application contacts, and the script now runs as designed.  Hopefully, we will not run into other scripts that assume the location in AD.

Cheers.

- Steve