• https://www.ocspedia.com/Misc/Explore_Dbimpexp.aspx?ArticleID=41
• https://blog.insideocs.com/2009/07/06/importing-and-exporting-ocs-user-contacts/

But we have really never had a good solution for end users.  The reason for this is two fold.  First the OCS server maintains your list of contacts server-side in a SQL database.  This is primarily to accomplish your contacts following you no matter where you login (anyone remember Exchange 2000 Instant Messaging?)  Second the backup and restoring of server data is typically considered to be an admin responsibility.  I am sure we don’t want a bunch of end users pumping huge lists of contacts into our database!

Anyway, that doesn’t seem to change the fact that many (many) users still want to make their own backup of their contact list.  I suppose in this day and age of (what I like to call) data irresponsibility I should applaud these people for wanting to do this.  :)

So here it is.  The only methods I am aware of (without the use of 3rd party) to export your own Communicator contact list.  Notice I didn’t say import?  Read on…

First Method (if you want to consider it a method)

1. In Communicator, right click on any contact and select copy
2. Open NOTEPAD, paste (you will get the address of the user)
3. Rinse and repeat for all desired contacts to export

Although I use the term loosely, to import simply copy from NOTEPAD and paste into the search bar in Communicator.  Assuming the user is not on your contact list, you may now add them.

Second Method (this is not pretty but it is an “export”)

1. Enable logging in Communicator (Tools, Options, General: ‘Turn on logging in Communicator’)
2. Sign out and back in
3. Open %USERPROFILE%\TRACING on the client
4. Locate the most recent Communicator-uccapi-0.uccapilog log file
5. Open this log file (NOTEPAD or SNOOPER)
6. Search for containers xmlns (this is a list of all contacts you are subscribed to)
7. NOTE: Search for subscribers xmlns, it comes next (this is a list of all contacts subscribed to you)

So there you have it.  Obviously, use at your own risk.  No support provided for either of these methods although they should be pretty harmless.  Only works for PC based MOC clients (no Mac, CWA or CoMo).  Your mileage may vary!  Enjoy!

/\/\arkBarr

Unified Communications How-To

Overview

The Microsoft Unified Communications “How-To” training tool is a Microsoft Silverlight™ 2 application that provides step-by-step instructions for common UC tasks. You can customize the How-To application to your company’s needs based on the UC features you’ve installed. For example, if you have installed all UC features except Communicator Mobile and Communicator Group Chat, you can modify the XML file so that those features and topics do not appear in the interface.

File Name: UCHowTo.zip

Version: 2007 R2

Date Published: 5/4/2009

Download details: Unified Communications How-To

Supportability is available for Office Communications Server 2007 R2 member server role on a Windows Server 2008 R2 operating system

SUMMARY

This article describes the supportability for the Microsoft Office Communication...

This article describes the supportability for the Microsoft Office Communications Server 2007 R2 member server role on a server that has a Windows Server 2008 R2 operating system installed. However, the following scenarios are currently not supported on a Windows Server 2008 R2 operating system:

• Upgrading the operating system to Windows Server 2008 R2 for an existing installation of Office Communications Server 2007 R2 is not supported.
• Deploying Microsoft Office Communications Server 2007 R2, Group Chat on a Windows 2008 R2 operating system or in a Windows 2008 R2 domain is not supported
• Office Communications Server 2007 R2 administration tools will only be installed in native 32-bit mode or a native 64-bit mode. Because of an application compatibility issue with Windows Server 2008 R2, installing Office Communications Server 2007 R2 administration tools in 32-bit mode on a 64-bit Windows 2008 R2 operating system is not supported.

Supportability is available for Office Communications Server 2007 R2 member server role on a Windows Server 2008 R2 operating system

By default, OCS 2007 clients all use TLS out of the box, which makes network tracing more difficult.  Since the traffic is encapsulated in TLS then you can really only see the endpoints and TLS negotiation.  This can be useful for some troubleshooting, but for my purposes of better understanding SIP it was not so good.  Good thing for me, there was pretty good proprietary logging built-in to the clients. 

Since the Messenger & Communicator 2005 clients were introduced, we have offered several types of log files.  With earlier clients it was necessary to edit the registry to enable this logging (more).  Starting with Communicator 2007 we moved this into the GUI which correlates to the same registry keys. 

The ‘Turn on logging in Communicator’ results in all diagnostic logging being enabled in the registry.  Where as the newer option ‘Turn on Windows Event logging for Communicator’ results in just local event logging.  Again, good for some things but not for reading SIP.

Ok, so after enabling the diagnostic logging and restarting Communicator, you can find these logs in the %USERPROFILE%\TRACING folder of  your client machine.  Among them will be the .UCCAPILOG and .ETL files.  The Communicator.ETL file is very proprietary.  It is only useful for sending to Microsoft for troubleshooting client side connections.

The .UCCAPILOG however is clear text and may be viewed with notepad or SNOOPER.EXE from the OCS ResKit. Using SNOOPER.EXE results in removing the tracing info and formatting the SIP packets to a nice readable format, definitely recommended!

And SNOOPER.EXE does have the ability to read the file while Communicator is running.  Using the Reload File command will allow you to refresh the latest entries for viewing.

So this was plenty for me to get ramped up on SIP protocol and start my adventure.  However, I went one step further looking for a method to see my SIP traffic real-time! 

In the UNIX world the TAIL command has been used for years to view real-time running log files.  There are many variations on this command for Windows and I have used them many times for monitoring SMTP or W3SVC logs.  I wonder?

One of my favorite Windows versions of this utility is BareTail from Bare Metal Software.  They offer a free and commercial version of the utility.  By downloading the free version, pointing it towards my .UCCAPILOG file I was able to see my SIP traffic real-time!

Another thing I like about BareTail is the ability to add filters to highlight specific entries.  By creating some SIP specific filters, I can now see at a glance my SIP traffic in real-time!

(IP’s and server names removed to protect the innocent!)

Have fun!

/\/\arkBarr

Microsoft readies Office Communicator 2010 beta

Posted by Mary Jo Foley @ 12:17 pm

As I’ve blogged before, the next release of Microsoft’s Office Communications Server is in development, with a final release slated for the last calendar quarter of 2010. But it looks like testers are going to be able to get their hands on to see a demo (possibly ) of a beta of one component of the 2010 release — the Communicator enterprise instant-messaging client. — before the end of March.

Microsoft readies Office Communicator 2010 beta | All about Microsoft | ZDNet.com

Office Communicator 2007 R2

The Following Office Beta Editions Contain Office Communicator 2007 R2

Professional Plus

Instant messaging at work will be a snap for you with Microsoft Office 2010, and so will all the related functions of your Microsoft Office Communicator 2007 R2 application. That’s because Office Communicator 2007 R2 is tightly integrated into Outlook 2010, and works seamlessly with the familiar Office applications that users employ daily.

[Link removed due to product now being released]

Q) Can I use Mac Messenger for LCS 2005 pools?

A) Only the Mac Messenger 6 client will work against LCS 2005, Mac Messenger 7 is required for OCS 2007 or OCS 2007 R2 pools.

Q) Can I do audio/video calls with Mac Messenger?

A) Mac Messenger 7 now supports AV calls as well as PC to PC calls, however no PSTN calls are supported.

Q) How may I get a network traces from a Mac Messenger client?

A) Wireshark does offer a version for the Mac, available here. 

However, if you are using OS X then there is a faster, easier way to do this built-in.  Using the terminal application you may enable tcpdump logging directly on the interface and collect a logfile this way.  Once done, this file may be opened (or converted) using Wireshark.

Find the terminal application (usually under applications/utilities)

Enter the following command to start the trace (you may need to provide an admin password)

sudo tcpdump –i en0 –w /users/USERNAME/LOGFILENAME.LOG

The –i switch is interface, en0 is the default adapter and –w is the output location for the log.  See resources below for a link to a full article on the syntax.

Once the trace is complete, use CTRL-C to stop the tracing.  Collect up the log at the location you specified.

Q) Can I get any logging from the Mac Messenger client?

A) Yes, logging is available via both the GUI and plist for the Mac Messenger client.  Unfortunately this logging is client application only and does NOT log SIP traffic.

Logging option as seen in the Preferences/General tab.

Logging option as seen in the com.microsoft.Messenger.rtc.plist file.

Both plist files for the Mac Messenger client (located under /Users/username/Library/Preferences).

Log file created once logging is enabled (located /Users/username/Documents/Microsoft Messenger.log).

The logging looks a little something like this (names changed for this post)

Microsoft Messenger 7.0.2 (090123)
MacOS version 10.4.9 (build 8S165)
2009/12/30 08:50:29.529  Office Communications Server LOGON STARTED:  USER = {DOMAINNAME\USERNAME}
2009/12/30 08:50:39.327 Trying HTTP connection to FQDNofOCSPOOL (port 443)
2009/12/30 08:50:39.327 Using proxy FQDNofPROXY (port 80)
2009/12/30 08:50:39.501 HTTP connection failed (114)
2009/12/30 08:50:39.501 HTTP transaction connect failed (114/0)
2009/12/30 08:50:58.319  Office Communications Server LOGON ENDED:  USER = {DOMAINNAME\USERNAME}
2009/12/30 08:50:58.641 Trying HTTP connection to images.edge.messenger.live.com (port 443)
2009/12/30 08:50:58.641 Using proxy FQDNofPROXY (port 80)
2009/12/30 08:50:58.686 Trying HTTP connection to components.premiumservices.aol.com (port 443)
2009/12/30 08:50:58.686 Using proxy FQDNofPROXY (port 80)
2009/12/30 08:50:58.922 Trying HTTP connection to sec.yimg.com (port 443)
2009/12/30 08:50:58.923 Using proxy FQDNofPROXY (port 80)
2009/12/30 08:53:49.507 Trying HTTP connection to FQDNofOCSPOOL (port 443)
2009/12/30 08:53:49.508 Using proxy FQDNofPROXY (port 80)
2009/12/30 08:53:49.678 HTTP connection failed (114)
2009/12/30 08:53:49.679 HTTP transaction connect failed (114/0)
2009/12/30 09:04:14.137  Office Communications Server LOGOFF ENDED:  USER = {DOMAINNAME\USERNAME}

Q) Ok, so can I get SIP logging from Mac Messenger?

A) Yes.  The easiest way is to collect logging from a PC client while talking to a Mac client, although this may not contain what you are looking for if the issue doesn’t involve IM features (ie. looking for in-band provisioning to the Mac client, etc.) 

Another method I have used is to create a TCP 5060 binding on the pool (not there by default in OCS 2007 but maybe added easily).  Then configure the Mac Messenger client to login via TCP 5060 using manual configuration.  Start a tcpdump trace and start the Mac Messenger client.  Once done, you should have a network trace over TCP 5060 so the SIP is in clear text and can be read.

Of course you could also enable SIP logging on the OCS pool, and filter specifically on the Mac user’s SIP address to collect SIP logging from the server side.

Q) Can I use Kerberos authentication with Mac Messenger?

A) Mac Messenger will support Kerberos authentication but it is only for the SIP login to the pool.  NTLM authentication will still be used for connections to the web services (i.e. address book downloads)

Q) Does the Mac Messenger client use the OCS Address Book?

A) Yes, the client downloads the ABS files in the same manner as the PC client and creates a GALCONTACTS.DB files located in /Users/username/Documents/Microsoft User Data/Messenger Corporate Data folder.

Q) Does the Mac Messenger client support distribution list expansion?

A) No, the client does not support this at this time.  If you have added DL’s (from a PC client) and then login from a Mac Messenger client, you will see the name but it will not expand.

Lots of other good information can be found in the Mac Messenger Deployment Guide(s), links below.  Items like installing certificates, uninstalling the client, items found in the plist file.  I know there are plenty of other questions that I might have missed, feel free to comment and I will try to address them.

Resources

• Microsoft Mactopia
• Mac Messenger download (see ‘Messenger for Mac’ at the bottom)
• Mac Messenger 7 Deployment Guide (online & downloadable version)
• Mac Messenger 6 Deployment Guide (download only)
• Previous Mac Messenger blog posts
• Mac OS X tcpdump syntax

For example, an existing OCS 2007 pool that is migrating to an OCS 2007 R2 pool, but something goes wrong with the R2 deployment.  So the customer tries to deactivate the server roles and remove the pool, but this doesn’t succeed.  As a result, some server roles are left activated and the pool has to be ‘force’ removed.  It appears from the OCS admin tool that the server / pool is gone.  When the customer tries to reinstall the server / pool with the same name(s), they run into errors since there are already object(s) in AD with the same name.  Now it becomes a chore of looking through the RTC Service container and all the objects to locate the specific entries.  Anyone who has had the pleasure of running ADSIEdit against a existing OCS deployment knows this is a time consuming and dangerous task.  This post will show you an easier, safer method for locating the specific entries for manual removal from AD.

Needed Tools

• ADSIEdit – To locate the distinguished name (DN) of the RTC Service object and later to manually delete the orphaned objects
• LDIFDE – To export out the RTC Service data to a text file
• Notepad – To search the exported data and list the orphaned entries
• FQDN’s of the server(s) you need to remove

NOTE: This procedure requires use of tools that could be very dangerous to your OCS deployment and AD in general if used incorrectly.  DO NOT proceed unless you are confident in the use of these tools and have the proper domain rights to perform the operation.

NOTE: Whenever possible, attempt to deactivate all OCS server roles and remove (even if you must force remove) the pool.  This will greatly reduce the number of entries you must manually delete later on.  For example, an OCS 2007 R2 Enterprise Edition deployment might be made up of 4 server nodes.  If 3 of these servers successfully deactivate and only one server has roles that will not deactivate, you have dramatically reduced the number of objects in AD to locate and remove.

1. Locate the RTC Service object in the System container – OCS 2007 originally recommended placing the objects in the root domain System container, OCS 2007 R2 changed this to the Configuration container.  The change was due to issues with customers with large deployments and unreliable communications with the root domain.  OCS 2007 R2 provided a migration script to allow you to move the objects, more about that here.  Anyway, many times customer do not know where the object reside and even if they do it’s a good exercise to verify.
   
   Using ADSIEdit.msc (Windows support tools), connect to the root domain and expand the System container.  Navigate to the Microsoft container and see if it contains the RTC Service object.  If it does have an RTC Service object, proceed to step 3.  If you don’t see the RTC Service object here, then proceed to step 2.
   
2. Locate the RTC Service object in the Configuration container – If you didn’t find the RTC Service object in the System container, then most likely it is in the Configuration container.
   
   Using ADSIEdit.msc (Windows support tools), connect to the current domain and expand the Configuration container.  Navigate to the Services container and see if it contains the RTC Service object.  If you don’t see the RTC Service object here, then you are either in the wrong domain OR OCS is not installed in this forest.  :)
   
3. Right click on the RTC Service object and select properties.  Scroll through the attributes and select the ‘distinguishedName’ attribute, click Edit.  Copy the distinguishedName to the clipboard.  We will need this later for our export command.
   
4. Now that we have the DN of the RTC Service object, we can use it to form the LDIFDE.exe command line to export all the data it contains.  Open a CMD prompt and type the following command;
   
   LDIFDE –d “” –f outputfile.txt
   
   Now paste the RTC Service DN from the clipboard in between the quotes.  The finished command should look something like this;
   
   for a System container location
   or
   for a Configuration container location
   
   Execute that command and a success should look like this;
   
   
5. Now type the following command (using your export filename) to view the exported data;
   
   NOTEPAD outputfile.txt
   
   Using the find menu item in Notepad, search for the FQDN of the server(s) you are interested in removing;
   
   In this case, UC_OCS_R2_SE.uc.vm.com
   
   As you find the entries, copy the dn: line above each section to a separate notepad to make your list of orphaned entries.  When you reach the end you should now have a list of each entry that still references the orphaned server object(s).  Repeat for each server FQDN you might be looking for.
   
6. Return to your ADSIEdit.msc window and locate the various entries you found above.  If you are 100% confident these are the correct entries, right click and delete them.  Wait for domain replication and you should be free of any orphaned objects referencing to old server names.
   

It’s not a bad idea to repeat this process again to verify that the FQDN’s you were interested are no longer present, especially after domain replication has completed.

I hope this helps.

/\/\arkBarr

Before I get into my technical postings, I would like to a moment to again thank my team both locally and across site for all the support and knowledge they have shared with me.  Without them I would not be able to do my job, period.  The Unified Communications team is still small, compared to Exchange or some other products.  That doesn’t change the quality of the work one bit, I assure you.  The team consists of both new as well as senior engineers, developers and managers that make working in this environment a true pleasure.  Thanks folks, thanks for everything.

Also, since some of those teammates do publish blogs of their own, I would like to specifically mention them here.  This list is by no means a complete listing of all blogs related to UC, but the ones that I know personally and have relied on daily for the past 2 years.

• Tom Laciano
• Scott Oseychik
• Dave Howe
• Greg Anthony
• Geoff Clark
• Martin Barron
• Ram Ojha
• Jithendranath Reddy

In addition, there are literally hundreds of blogs related to UC, created by employees, solution providers and customers too.  All valuable in their own way, here is a link to a recent list of all UC blogs; https://communicationsserverteam.com/archive/2009/08/11/550.aspx

Finally, there are a couple of UC related Twitter feeds you might want to follow as well;

• UCTeam
• DrRez

Now after composing this post and seeing all the great knowledge already published out there, I am back to wondering what could I possible add to this?  Well, we will just have to see.  :)

Mark “/\/\arkBarr” Barringer