7/19/2010

TechNet Blogs

RUI SILVA - UCSPOTTING

The Ultimate Question of Life, The Universe, and Everything (if time permits, some useful SQL queries about OCS users)
Wed, Jun 30 2010 by ucspotting

First, lets take care of the Ultimate Question of Life, The Universe, and Everything, since this one is really, really easy. Well, the answer is 42. Now, on with the useful (so I hope) SQL queries that will let you know a little bit more about your environment. In order to build valuable SQL queries, one must know the backend data structure that supports Office Communications Server (OCS) 2007 R2. The TechNet page Storage Requirements has a nice table that enumerates the different databases created on a default OCS installation, whether its Standard Edition or Enterprise Edition:

Database Type of Data RTC

Location

Persistent user data (for Enterprise Edition, back-end database; example, ACLs, contacts, home Standard Edition, Microsoft SQL Server server or pool, scheduled 2005 Express with SP2. conferences)

RTCConfig Persistent Office Enterprise Edition, back-end database; Communications Server 2007 R2 Standard Edition, Microsoft SQL Server settings 2005 Express with SP2. RTCDyn Transient user data (for example, Enterprise Edition, back-end database; endpoints and subscriptions, and Standard Edition, Microsoft SQL Server transient conferencing state) 2005 Express with SP2. Enterprise Edition, back-end database; Database containing global Standard Edition, Microsoft SQL Server address information used by Address Book Web query service 2005 Express with SP2. to support Address Book search queries from Communicator Mobile for Windows clients

RTCab

http://blogs.technet.com/b/ucspotting/

1/19

7/19/2010

TechNet Blogs

All the information used in the queries resides on these databases. To execute the queries, Ill use Microsoft SQL Server Management Studio (actually Ill use the Express Edition, since I have OCS Standard on my test environment).

Query #1 List users that have logged in OCS

For this query, the needed information resides on the RTCDyn database, more specifically at the dbo.HomedResourceDynamic table, which contains the LastNewRegister field (last logon time) and the ResourceId field (ID of the user). Since we want to display SIP Addresses and not user IDs, well cross information with the UserAtHost field, that resides on the dbo.Resource table from the RTC database. This is the SQL query
SELECT hud.LastNewRegisterTime AS "Last Logon", res.UserAtHost AS "SIP Address" FROM rtcdyn.dbo.HomedResourceDynamic hud JOIN (SELECT ResourceId, UserAtHost FROM rtc.dbo.Resource GROUP BY ResourceId, UserAtHost) res ON hud.OwnerId=res.ResourceId ORDER BY "Last Logon" DESC

that will produce the following result:

Query #2 List users that have at least one contact in Communicator

Although adding contacts (or buddies) in Office Communicator is not required to take advantage of all the features provided by OCS, an Administrator might find useful to know which users have at least one buddy in their list of contacts. The information needed resides on the RTC database, more specifically at the dbo.Resource table. The query looks like this:
http://blogs.technet.com/b/ucspotting/ 2/19

7/19/2010

TechNet Blogs
SELECT DISTINCT r.UserAtHost FROM RTC.dbo.Contact c INNER JOIN RTC.dbo.Resource r ON c.OwnerId = r.ResourceId

And heres a picture of the results obtained.

Query #3 List users that have Enterprise Voice enabled

OCS stores the configuration of the different user features that are enabled in (at least) 2 locations: in the table dbo.ResourceDirectory, field OptionFlags, on the RTC database; in the Active Directory, in the msRTCSIP-OptionFlags attribute. In this example Ill use a SQL query to find that information on the RTC database.
SELECT r.UserAtHost FROM RTC.dbo.ResourceDirectory c INNER JOIN RTC.dbo.Resource r ON c.ResourceId = r.ResourceId WHERE (c.OptionFlags & 128) = 128

In my test environment, I have the following UC Enabled users:

http://blogs.technet.com/b/ucspotting/

3/19

7/19/2010

TechNet Blogs

Query #4 List users that organized Live Meeting conferences

If someone wants to know the users that have organized Live Meeting conferences, that information is stored on the RTC database, dbo.Conference table, OrganizerId field.
SELECT DISTINCT r.UserAtHost FROM RTC.dbo.Conference c INNER JOIN RTC.dbo.Resource r ON c.OrganizerId = r.ResourceId

The following image depicts the results from my test environment:

The answer to this question could also be obtained by using the Resource Kit tool DMInside with the option
http://blogs.technet.com/b/ucspotting/ 4/19

7/19/2010

TechNet Blogs

List organizers.

Want more reports?

OCS records much more information and keeps track of several indicators about pretty much everything related with the different forms of communications available to the users. Deploying Monitoring Server will unleash all the potential of OCS reporting. Curtis Johnstone has written a nice blog post about other reporting possibilities that I strongly recommend you to read.

RUI SILVA - UCSPOTTING

Dude, Wheres my CDR/Archiving/QoE Data?

Wed, Jun 16 2010 by ucspotting

Recently I had to troubleshoot a strange case where a recently OCS Archiving + Monitoring server (collocation of these 2 roles is supported) was not collecting any data. I was monitoring the data through the use of this neat Resource Kit tool: ArchivingCDR Reporter (ArchivingCDRReporter.exe, ArchivingCDRReporter_Config.xml) This reporting tool has built-in SQL queries to retrieve and view information from the Archiving and Call Detail Records (CDR) Back end. The tool enables the user to view Office Communications Server 2007 usage reports based on the Archiving and CDR tables. Everything seemed to be pretty well configured, Archiving and Monitoring were enabled both at the forest level and pool level, as explained in Deploying Monitoring Server and Deploying Archiving Server. The Operating System was Windows Server 2008 R2, but since all the steps from KB982021 had been followed, that version of OS is fully supported. So, I had to stop for a while and think Looking at the archiving and monitoring architecture in Office Communications Server 2007 R2 may help a little bit:

Since no data was being delivered to the DB server and the connection between the OCS Archiving + Monitoring server was OK, maybe the problem had to do with the Messaging Queuing (MSMQ) service. In fact, the Application event log of the server had a couple of error events related with MSMQ: The Message Queuing service rejects incoming messages when it is unable to check whether the sender is allowed access to the queue for sending messages. In this case, the queue affected is OCS-ARCHMON\private$\lcslog, but note that an event might not be issued every time this problem occurs. To perform this access check , Message Queuing needs access to the Tok enGroupsGlobalAndUniversal attribute of the sender's user object. Only users with domain administration permissions can add members
http://blogs.technet.com/b/ucspotting/ 5/19

7/19/2010

TechNet Blogs

to the Windows Authorization Access Group, which is allowed access to the Tok enGroupsGlobalAndUniversal attribute, in one of two ways: 1) For best security practice, add only the computer accounts that need access to the Tok enGroupsGlobalAndUniversal attribute to the Windows Authorization Access Group. The domain administrator will repeat this operation for other Message Queuing computers that require the permission, manually adding the relevant accounts to the Windows Authorization Access Group. 2) As a less secure practice, add the Authenticated Users group to the Windows Authorization Access group. This grants every authenticated user, including the Message Queuing service on any computer, access to the Tok enGroupsGlobalAndUniversal attribute for all users, and requires no further manual administration.

I followed the suggested recommendation of adding the MSMQ computer accounts (OCS Frontend, OCS Archiving + Monitoring) to the Windows Authorization Access Group (located in the Builtin container).

http://blogs.technet.com/b/ucspotting/

6/19

7/19/2010

TechNet Blogs

After that, in order to correct the problem, you must restart the MSMQ service on the Archiving + Monitoring server (this will also restart the OCS services). On the OCS Frontend you must also restart the MSMQ service, the QoE Agent Service and also the Frontend service. Restarting both servers will also do the trick.

RUI SILVA - UCSPOTTING

How to apply updates for OCS

Thu, Nov 26 2009 by ucspotting

From times to times, new updates are released for Office Communications Server 2007 R2, in order to correct bugs or to fix some security vulnerabilities. As part of the normal operations routine, the IT Administrator should decide whether to apply or not apply these hotfixes, although nowadays its practically common sense to reserve a maintenance window to effectively install corrective software. The first thing to have in mind is the risk associated with this kind of operation, in order to prevent situations like the recent one with the KB974571 hotfix. But after the planning process and the risk mitigation phase, its time to apply those patches. Taking the OCS 2007 R2 October 2009 hotfix as an example, the first thing to notice on the download page is there are several files to install:
http://blogs.technet.com/b/ucspotting/ 7/19

7/19/2010

TechNet Blogs

These files are intended to be downloaded and installed on the different OCS roles (most of the roles require more than one file to be installed). The question one may ask is Which patches should be applied on a given role?. Well, fear not, as Im going to explain 3 different methods that can be used in order to correctly apply the updates with a minimum effort.

Method #1 Microsoft Update or WSUS

Using Microsoft Update or Windows Server Update Services (WSUS) is by far the simplest method. The main difference between the two is that the first installs the updates directly from the Microsoft site, whether the second goes through an internal approval process by an IT Administrator before downloading and distributing the required updates. But both methods will automatically deliver the relevant update files to all the OCS roles in your infrastructure. Depending on the update process configured on each server, the updates will then need to be locally approved and given permission to run (or not).

Method #2 - Cumulative Server Update Installer

The Cumulative Server Update Installer (ServerUpdateInstaller.exe) is a tool that can be downloaded together with the rest of the patches. This tool applies all updates for the appropriate server role in one click.
http://blogs.technet.com/b/ucspotting/ 8/19

7/19/2010

TechNet Blogs

Nevertheless this is still a manual method run from the command line or from the Windows UI: 1. Download *ALL* the files to a local folder and run ServerUpdateInstaller.exe. The Cumulative Server Update Installer can be run using the UI, by double clicking it (see image below), or using the command line.

To run the Installer by using a command prompt, use the following command, together with the appropriate switches: ServerUpdateInstaller.exe [/silent [/forcereboot]] | [/extractall] The /silent/forcereboot switch applies all the applicable updates silently and then automatically restarts the server at the end of the installation process if it is necessary. The /extractall switch the updates from the installer and puts the updates in a subfolder that is named Extracted in the folder in which you ran the command. 2. Since we are using the October 2009 hotfix as an example, this update requires a database upgrade. The database upgrade patch can be applied manually by using the provided OCS2009DBUpgrade.msi file. The update should be installed on every front-end and director server running OCS Standard Edition, and/or from any Enterprise Edition front-end or backend (backend preferred). More details and instructions can be found on the corresponding KB article: Description of the update package for Office Communications Server 2007 R2 Database.

Method #3 Manual Installation

And finally the 3rd method, which I dont recommend but that Ill explain for academic purposes. Please keep in mind the following recommendations for manual deployment (from KB968802 article): All updates for a role must be deployed. Additionally, all updates on the same server role must be at the latest update level. Communications Server Standard Edition and Communications Server Enterprise Edition Consolidated also require all updates for any roles that are deployed on the server. All updates must also be at the latest update level. Additionally, the following recommendations apply to the for Office Communication Server 2007 R2 Distributed Enterprise Edition: Update the whole topology with the latest updates for each component at the same time. This may be possible in smaller environments. First, update the pool and the directors who are servicing the pool. Update additional pools as possible with the directors for these pools at the same time. If a director services more than one pool, the director is updated while the first pool that it services is updated. The external
http://blogs.technet.com/b/ucspotting/ 9/19

7/19/2010

TechNet Blogs

pool servers must be updated after the pool that they service is updated. (CWA and media) If an external pool server services more than one pool, it will be updated after all the pools that it services are updated. Having said that, the following table (click for larger size) helps you determine the mapping between the updates and the different server roles (courtesy of my colleague Joo Bravo, kudos to him):

Just follow the greens and apply the update files to each OCS server role according to the previous table.

Keeping up with the updates

If using any of the manual processes described above (methods 2&3), the best way to keep up with the latest OCS updates is to regularly check the new Updates Resource Center for Office Communications Server 2007 R2 and Clients on the OCS TechCenter.

RUI SILVA - UCSPOTTING

Tales from the Crypt..oAPI Vulnerability (KB974571)

Thu, Oct 15 2009 by ucspotting

As much as I would like to catalog the story so far around KB974571 as fiction, the truth is that it resembles more to a horror movie. Before going any further, I would like to say that Microsoft recommends thorough testing of any software patch/hotfix before applying them in a Production environment. Having said that, I would like to invite you all to read Best Practices for Applying Service Packs, Hotfixes and Security Patches. The above mentioned TechNet article states the following: The basic rules are: "The risk of implementing the service pack, hotfix and security patch should ALWAYS be LESS than the risk of not implementing it." And, "You should never be worse off by implementing a service pack, hotfix and security patch. If you are unsure, then take steps to ensure that there is no doubt when moving them to production systems." Whether youre superstitious, religious or a devoted fan of Murphy Laws, the naked truth is that sh*t
http://blogs.technet.com/b/ucspotting/ 10/19

7/19/2010

TechNet Blogs

happens! And thats exactly what recently happened with OCS and the release of the security patch KB974571. For more information, please read the post from the OCS Team Blog: Urgent: Known issue under investigation with KB974571 and LCS/OCS. But the KB974571 hotfix has another side effect that I recently experienced. Besides affecting the services of LCS/OCS, the very same patch can also prevent the installation of new OCS servers. Recently, I was building a new demo environment, when, nearly at the end of the installation of a standard edition server, during the activation phase of the server, I got the following error:

The OCS installation logs revealed the following information: Failure [0xC3EC796C] One or more errors occurred during execution of the wizard; the wizard was unable to complete successfully. Please check the log file for more information.

http://blogs.technet.com/b/ucspotting/

11/19

7/19/2010

TechNet Blogs

After expanding the log, the error pointed out to the Activation Standard Edition Server Log.

The error in the Activation Standard Edition Server Log was: Failure [0xC3EC78D8] Failed to read the Office Communications Server version information. This can
http://blogs.technet.com/b/ucspotting/ 12/19

7/19/2010

TechNet Blogs

happen if the computer clock is not set to correct date and time.

After spending some time troubleshooting the issue, with no solution in sight, I started to doubt the health of the virtual machines I was using (first) and then my sanity (last). But then, when I was on a dead end, a customer asked me to help him installing a new Edge Server. Guess what? Same error, same problem. Since I was getting lots of noise around KB974571 (I already knew it could affect installed LCS/OCS services), I decided to uninstall that specific hotfix from the list of installed patches. That solved the problem!

Microsoft recommends to postpone installing KB974571 on any LCS 2005 / OCS 2007 /OCS 2007 R2 servers.
http://blogs.technet.com/b/ucspotting/ 13/19

7/19/2010

TechNet Blogs

Microsoft is investigating this issue, and will determine the most appropriate way to address it. Customers who are not running OCS or LCS server are not affected by this k nown issue, and can safely ignore this issue. Customers who have deployed the OCS or LCS product on a server should assess the risk that is involved to decide whether to install the security update on that server. These customers should revisit this Knowledge Base article often, because this article will be updated as soon as more information and a resolution are available.

[UPDATE]
There is now a fix for this issue, available through the KB974571 article. Look under the section Resolution for the known issue.

RUI SILVA - UCSPOTTING

Live Meeting: Best Before Date (See Below)

Fri, Aug 14 2009 by ucspotting

Although on-premises web conferencing meetings organized with Office Communications Server (OCS) are not perishable products (and thus they dont require a best-before date), there is some configuration involved around meeting life-cycle that I would like to explore a little bit further.
http://blogs.technet.com/b/ucspotting/ 14/19

7/19/2010

TechNet Blogs

Suppose you organize a web conference using the Live Meeting client or the Conferencing Add-in for Microsoft Outlook. You invite some attendees and during the meeting some content is generated and uploaded (e.g. PowerPoint slides, polls, whiteboard, etc.). Three weeks after this specific meeting has occurred, you want to review some of the annotations that were made on the slides and some of the brainstorming carved on the whiteboard. No problem, you think. After locating the appointment on the Outlook Calendar, you click the Join the meeting hyperlink, but suddenly the following error pops-up:

The meeting has ended or the information you entered was not recognized. Contact the meeting organizer for more information.

Before going any further, lets review some of the concepts associated with meeting life-cycle: Deactivation The meeting is deactivated when the organizer terminates it and all the authenticated users leave. When you deactivate a meeting, you end the instance of the meeting, but the meeting continues to exist in the database and can be reactivated and rejoined. Expiration After the meeting is deactivated, the expiration clock starts ticking. When you reach the expiration time, its no longer possible to rejoin the conference, unless its reactivated. The default expiration time for scheduled meetings is 14 days. Reactivation If the meeting still exists in the database, it can be reactivated simply by rescheduling it using Outlook. Since you can reschedule it to occur in the past (although I cant think on a reason to do this), the meeting will only reactivate if it falls in the last 14 days, because this is the default expiration time. Content Expiration Grace Period Grace period in addition to the expire time, after which the Web Conferencing Server should clean up content for a conference. When you reach the end of the grace period, the meeting and all associated meeting content are deleted from the database. The default grace period is 14 days after the expiration time. With the present release of OCS its not possible to control the duration of the meeting expiration period
http://blogs.technet.com/b/ucspotting/ 15/19

7/19/2010

TechNet Blogs

(although the content grace period can be extended). This is the default behavior for the meeting expiration time (txs Tarang Mittal): For a single one time scheduled meeting, the conferences expires after 14 days. For a recurring meeting, the conference expires 14 days after the last instance of that meeting. For a recurring meeting with no end date, the conference never expires. For a Meet Now, the session expires in under 8 hours. Hopefully, after this explanation we can now understand the error message we got when trying to rejoin a meeting that had ended 3 weeks before. Since the expiration time is 14 days, its no longer possible to rejoin it. The good news is that we have an additional 14 days for the content to expire, after the default meeting expiration period. So, by simply rescheduling the meeting using Outlook, we can now successfully reopen it and check the content we were looking for.

Managing Meeting Life Cycles with WMI

There are some parameters in OCS that can only be controlled using WMI, such as the ones involved with meeting life-cycle. For conference deactivation, there are two pool-level WMI settings that are stored as properties in the MSFT_SIPMeetingScheduleSetting WMI class in the root\CIMV2 namespace: UnAuthenticatedUserGracePeriod [Integer (0~60) minutes] Grace period allowed for anonymous or federated users to stay in the meeting without any authenticated user in the meeting. The default value is 10 minutes. MaxMeetingLength [Integer (0 ~ 8760) hours] Maximum length of any meeting without join activity. The default value is 24 hours. For conference expiration, there is one pool-level WMI setting that is stored as a property in the MSFT_SIPDataMCUCapabilitySetting WMI class in the root\CIMV2 namespace:
http://blogs.technet.com/b/ucspotting/ 16/19

7/19/2010

TechNet Blogs

ContentExpirationGracePeriod [Integer (0~365) days] Grace period in addition to the expire time, after which the Web Conferencing Server should clean up content for a conference. The default value is 14 days.

To use VBScript to modify deactivation and expiration WMI settings The following 2 scripts will modify the WMI properties previously discussed. They must be run on the OCS Web Conferencing Server using the appropriate administrative permissions.

http://blogs.technet.com/b/ucspotting/

17/19

7/19/2010

TechNet Blogs

To use WBEMTest to modify deactivation and expiration WMI settings 1. Log on to a server with Office Communications Server 2007 R2 administrative tools installed, as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights. 2. Click Start, click Run, type wbemtest, and then click OK. 3. In the Windows Management Instrumentation Tester dialog box, click Connect. 4. In the Connect dialog box, in Namespace, type root\cimv2, and then click Connect. 5. In the Windows Management Instrumentation Tester dialog box, click Query. 6. In the Query dialog box, type the following in the Enter Query box according to the WMI class name to be modified and then click Apply: MSFT_SIPMeetingScheduleSetting Select * from MSFT_SIPMeetingScheduleSetting where backend="(local)\\rtc" MSFT_SIPDataMCUCapabilitySetting Select * from MSFT_SIPDataMCUCapabilitySetting where backend="(local)\\rtc" For an OCS Enterprise pool back end="server name\\sql instance"

7. In the Query Result dialog box, double-click the result.

http://blogs.technet.com/b/ucspotting/

18/19

7/19/2010

TechNet Blogs

8. In the Object editor dialog box for the WMI class, double-click the property you want to edit in Properties: 9. If you specified the MSFT_SIPMeetingScheduleSetting WMI class in step 6 of this procedure, double-click UnAuthenticatedUserGracePeriod or MaxMeetingLength.

10. If you specified the MSFT_SIPDataMCUCapabilitySetting WMI class in step 6 of this procedure, double-click ContentExpirationGracePeriod. 11. In the Property Editor dialog box, change the value to the new value in the Value box, and then click Save Property. 12. When you are finished with the editing, in the Object editor dialog box, click Save Object. 13. Close all dialog boxes, and then close Windows Management Instrumentation Tester. 14. To verify that the change was applied, open Event Viewer and look for event ID 56015. For more information, please read Managing Meeting Life Cycles.

http://blogs.technet.com/b/ucspotting/

19/19