If only I could

Recall all the words you wrote.

Export archiving.

 

As you probably know, Microsoft Lync Server 2010 enables you to archive all the instant messaging sessions that your users take part in. (Have we talked about that in a previous haiku? Well, now that you mention it, we believe we have. And on the Anniversary of the Oil Expropriation Day, no less!)

 

Note. We're going to keep things simple today and just talk about instant messaging sessions. However, you can also archive transcripts of your Web conferencing sessions.

 

Of course, that's all great, except for one thing: now that we have transcripts of all those instant messaging sessions safely tucked away in an archive, how do we actually get those transcripts out of the archive so we can do something with them?

 

Well, one way you could do this is to open up the archiving database (LcsLog) and try to extract the data for yourself. In theory, that would work. In practice, well, there are 20 or so different database tables to deal with, and users are not identified by their display name or SIP address but by a numeric code (e.g., 1) assigned by the system, and – well, there simply has to be a better way to do this, right? Surprisingly enough, however, there isn't.

 

No, hey, just kidding. As it turns out, there is a better way to extract instant messaging transcripts from the archiving database: all you have to do is use the aptly-named Export-CsArchivingData cmdlet.

 

Had you worried there for a second, didn't we?

 

Export-CsArchivingData is an interesting little cmdlet. What you do is this: you tell Export-CsArchivingData what transcripts you want to export and then you export them.

 

Ah, good question: what choices do you have when it comes to exporting transcripts? Well, there are primarily two options available to you. First, you need to specify the time period for those transcripts. For example, suppose you want to see all the transcripts for the month of March, 2011. In that case, you'd want to see transcripts for all the sessions that occurred in, well, March, 2011. That would mean sessions that had a start date on or after March 1, 2011, and an end date on or before March 31, 2011. Make sense? Of course it does.

 

In addition to that, you can limit your exports to sessions that involved a specific user. For example, say you only want to look at the transcripts involving Ken Myer. That's fine; just include the UserUri parameter followed by Ken Myer's SIP address (just be sure you leave off the sip: prefix). When you do that, you'll get only transcripts for sessions that Ken Myer participated in.

 

You know what? Maybe it would be better if we just showed you a sample command or two. OK. Here's a command that retrieves all the instant messaging sessions that took place in March, 2011:

 

Export-CsArchivingData –DBInstance atl-sql-001.litwareinc.com\Archinst –StartDate "3/1/2011" –EndDate "3/31/2011" –OutputFolder "C:\Logs"

 

Pretty easy, huh? Basically we just need to include the DBInstance parameter and specify the location of the Archiving database we want to pull records from, and then the StartDate and EndDate parameters. Oh, and don't forget the OutputFolder, which specifies the folder where the archived data should be stashed.

 

If you want just the transcripts that pertain to Ken Myer, then tack on the UserUri parameter as well:

 

Export-CsArchivingData –DBInstance atl-sql-001.litwareinc.com\Archinst –StartDate "3/1/2011" –EndDate "3/31/2011" –OutputFolder "C:\Logs" –UserUri "kenmyer@litwareinc.com"

 

As we noted earlier, you can configure your system to archive Web conferencing transcripts as well as instant messaging transcripts. If you only want to export the instant messaging transcripts then just add the ExcludeWebConfArchive parameter, like so:

 

Export-CsArchivingData –DBInstance atl-sql-001.litwareinc.com\Archinst –StartDate "3/1/2011" –EndDate "3/31/2011" –OutputFolder "C:\Logs" -ExcludeWebConfArchive

 

Man, this is almost as much fun as the Anniversary of the Oil Expropriation Day!

 

So what does it actually mean to "export" archiving data? Well, when you run the Export-CsArchivingData cmdlet, you'll create a subfolder in the output folder, a subfolder named after the database instance. In our sample, that means we end up with a folder path that looks like this:

 

C:\Logs\atl-sql-001.litwareinc.com_Archinst

 

Inside that subfolder you'll have another subfolder, one based on today's date. Because today is April 14, 2011, that meant we ended up with the following subfolder:

 

C:\Logs\atl-sql-001.litwareinc.com_Archinst\20110414

 

If you're starting to worry that this is like those little Russian nesting dolls, where every time you open one doll you find another doll inside, well, don't worry: it's not quite that bad. Fortunately, there aren't any subfolders inside this last subfolder; instead, we simply have a bunch of files with names like these:

 

201104141531008083_1_p2p.eml

201104141531001730_1_p2p.eml

 

Note. In case you're wondering, those names are based on the date and time that the individual transcript was exported (we think) and the fact that there were peer-to-peer instant messaging sessions (that's what the p2p is for).

 

If you have no idea what a .eml file is, well, don't feel bad: we had no idea what a .eml file was either. As it turns out, however, archived transcripts are exported as Outlook Express Electronic Mail files. We have to admit that we were a little skeptical about that, but guess what? When we double-clicked one of those files, they opened up just fine in Outlook Express:

 

 

 

Is that kind of a hassle? Well, yes, as a matter of fact it is. But, as it turns out, all you have to do is change the .eml file extension to a .mht file extension and you can then open these files in Internet Explorer:

 

 

Seemed a little easier to deal with than Outlook Express.

 

Actually, Notepad was our first thought, too. Unfortunately, though, it didn't work. The files opened just fine, but the transcript portion was encoded:

 

 

Unfortunately, our MIME base64 skills are a little rusty, so we couldn't just look at that message and decode it on the fly. So we went back to using Internet Explorer.

 

That's pretty much all there is to it. It's not the most sophisticated little exporting system we've ever seen, but it works.

 

Which is more than can be said about some of us.

 

Speaking of which, isn't it break time yet ….