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-1In my case, our instance of Lync was upgraded from OCS, to OCSR2, and then to Lync.
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
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