OCS Deploy Series: Archiving Server

I went through and reviewed my original postings about the Deployment Series and my initial approach after I completed the archiving server install. Oh well an undocumented bonus item, in the end I need to have the entire solution deployed including some still beta bits.

Archiving setup is not really that bad - you need a SQL Server Instance, I chose SQL 2005 and the default instance because I have an SE deployment. I installed the Archiving Service on my SE server but could have easily installed on the SQL server itself (I am not a SQL DBA by a long stretch but in my mind I like have SQL only be a storage location and any services running on other servers).  In short I did what is documented in the OCS Archiving document. So what do I show you, I mean how do you know that you have actually archived the data?

In my deployment Archiving was not working right away so I stopped and started all the services. Once that is done I monitor the event logs for any errors and conduct an IM session, with no errors I then open Computer Management and find Message Queuing under Services to make sure the queue length is zero.


ALERT: If you select the Shut down server if archiving fails option for Archiving on the pool properties for front-end, this is about data not reaching the SQL database, data reaching the message queue is working. For those dealing with compliance this could be an important area to investigate. At this time I don't have much information to help you with other than the alert.

Two users have an IM conversation about the new archiving functionality and I show some of the answers you get from the ArchivingCdrReporter Resource Kit tool.


The above screen shot shows the IM conversation and the report showing 1 conversation


This second screen shot shows the number of minutes that session lasted. This required that I closed the IM session on at least one endpoint, otherwise the value is null.


This last diagram is showing the users, note that this 1 test between these two users so you would expect much different results in a corporate deployment.

Remember Terry's comment in the IM - what about the content is it archived? This tool doesn't help much with the content aspect. So here is what you do when you have enough knowledge to be dangerous -

Open Microsoft SQL Server Management Studio, connect to the instance and open the database (ocsarchive is what I chose to name mine (not the default by the way)) and select tables. Find the Messages table, right click and select Open Table and here is the result


Notice that I chose to highlight the last line in the conversation to emphasize the content point. By the way did you notice that the first message in the thread, "Hi Terry" is plain to see? I recall a question about this but not sure we had an answer, regardless it is expected.

So there you go, just when you thought Tom would never return to the Deployment Series. Alas I gave you something you weren't told about so I have to get back to the items I first promised. I am not sure but I might try CWA and CoMo next simply because they are easier for me with my past experience.

G'night from the OCSKid

Screen clipping taken: 10/4/2007, 8:48 PM

Comments (2)

  1. Anonymous says:

    Golan Edri,

    Thanks for following up on the format of the conversation. The quick answer is that we do not have any other tools with the product to assist with handling the multiple versions. However, my team mate has some powershell scripts that he has been using and we are looking at how we can make those available. We have a few options but each has its pros and cons. I have plans to test them this week while waiting on the recommended approach to share.

  2. Golan Edri says:

    hi Tom,

    the most issue that you not mention for us , is the "body" message" of conversation that we see today like "junk".

    there is a plan to release a new tool or 3 party?

    because today i have to export the body to RTF format to look the full conversation.


Skip to main content