Quick brain dump really for replacing a physical OCS 2007 R2 Edge Server with another physical server. Note this method is effectively a swap out, i.e. the new server is named and numbered the same as the old server which was useful in my scenario as no firewall rules needed to be updated. This does mean of course that there is a brief outage during the old switcheroo.

First, identify and build up your new server with Windows Server 2003 x64 R2 with Service Pack 2. Install Windows Updates as per your company’s policy, but do not install KB974571 (MS-09-056) – although, there is a fix which is explained in the article if you absolutely have to install that update (see the ‘Resolution for these known issues’ section of the article). At this stage, name and number the new server differently to the existing server (also, at this stage you probably only need the inside interface online, though both NICs should be patched for production).

Next, on the existing server, export the certificates as a PFX package (cert + keys) so they can be imported on the new server. To export the certificates, open Computer Management -> Services and Applications -> Right-Click Office Communications Server 2007 R2 and choose Certificates. Hit Next > select Export a certificate to a .pfx file, select the first valid certificate (there should be at least two, one for the inside one for the outside), hit Next > provide a path and file name (leave the checkbox select to attempt to export the chain), hit Next > provide a password which you will later use to import the cert, hit Next > and complete the wizard. Repeat for the remaining valid certificate(s) – you will only need the certificates that are applied to each of the interface roles (Access, Web Conf, Internal, etc).

Also, use lcscmd.exe to export the existing server configuration so we can import on the new server. Run lcscmd similar to this (note the fqdn is the internal name of the server):

"%CommonProgramFiles%\Microsoft Office Communications Server 2007 R2\lcscmd" /config /action:export /level:machine /configfile:<path_to_xml_file> /fqdn:<fqdn_of_server>

Copy the exported XML config file and the .pfx cert files to the new server.

At this point you are ready to shut down the existing server, this is the old switcheroo. You could of course switch a couple of these steps around to keep the old server up a bit longer but the whole process from now takes only around 20 minutes…up to you. Also up to you but possibly a good idea, either change the IP address or disable the NICs of the existing server before shutting it down just to b safe.

• Rename the new server to take the host name of the old server
• Renumber the new server to take the inside and outside IP addresses of the old server
• Launch OCS 2007 R2 setup on the new server, go to Deploy Other Server Roles -> Deploy Edge Server.
• At Step 1, click Install and follow the wizard to install the application files.
• Run Step 2, Activate Edge Server, this will ask for account information for the RTCProxyService account.
• Run Step 3, Configure Edge Server, the wizard allows for the import of a config file, point the wizard to the XML file copied over prior to shutting down the old server. Each step of the wizard will display and allow you to update any of the imported settings if necessary.
• Run Step 4, Configure Certificates for the Edge Server, the wizard allows for the import of .pfx files. Match up the internal certificate with the internal interface role and the external certificate(s) with the external roles.
• Run Step 5, Start Services, if everything went well the services should come online.

You can run the validation process, Step 6, but since the Edge Server has just replaced another one, you should know pretty quickly if things are working or not (test federated contacts, public IM connectivity, external client connectivity, etc). You can also use Microsoft’s Remote Connectivity Analyzer

Popularity: 20% [?]

Found this post [blogs.technet.com] for configuring additional custom reports / SQL queries using the OCS Archiving CDR Reporter Tool (look for the heading ‘Some useful SQL queries’). However, it may be specific to OCS 2007 (not R2). The format of the queries in the XML file require some modification to work in R2 (for me anyway). When the queries are added to the Archiving CDR Reporter Tool’s config file (ArchivingCdrReporter.xml located in the ..\ResKit\ArchivingCdrReporter folder), they gave a “No database alias” error as follows when the tool was next run:

First thing that needs to happen is the queries need to have a database alias specified since their are two logging databases, CDR and Archiving and this tells the tool which database the query applies to. At the end of each query, between the </Value> and </Query> tags, need to add:

<Description>Archiving</Description>

These queries use the LcsLog, i.e. Archiving database. After that was done for each query, you may then got a “NullReferenceException” error:

To fix that, a tag needs to be added between the </Value> and <Database> tags for each query containing CDATA information such as:

<Description>
<![CDATA[ Query Description :   This query returns ... ]]>
</Description>

Once that is done, the tool should open and you should see the new queries available under the ‘More reports’ section in the tree.

Also, you can edit the queries that specify a User URI to make the address a variable so that it can be modified at runtime rather than in the XML file. For example: the “All IMs Sent by User” query can look like this in the XML file (note use of User1Filter(Users.UserId) at the end of the query):

<Query>
      <Name>All IMs Sent by User</Name>
      <Value>Select * from Messages, Users where Users.UserId = Messages.FromId and User1Filter(Users.UserId)</Value>
      <Description>
<![CDATA[
Query Description :
  The query returns ...
]]>
      </Description>
      <Database>Archiving</Database>
    </Query>

That will allow you to enter a value in the tool’s ‘User1 (SIP URI)’ field, much more convenient than setting a value in the XML file and re-running the tool each time.

Popularity: 47% [?]

How to find out the SIP URIs of users connected on one particular OCS Front End server – Ram Ojha’s Blog – Site Home – TechNet Blogs.

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

Popularity: 9% [?]