TechNet Blogs1

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

0

First, let’s 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 it’s Standard Edition or Enterprise Edition:

Database Type of Data Location

RTC Persistent user data (for

example, ACLs, contacts, home

server or pool, scheduled

conferences)

Enterprise Edition, back-end database;

Standard Edition, Microsoft SQL Server

2005 Express with SP2.

RTCConfig Persistent Office

Communications Server 2007 R2

settings




RTCDyn Transient user data (for example,

endpoints and subscriptions, and

transient conferencing state)




RTCab Database containing global

address information used by

Address Book Web query service

to support Address Book search

queries from Communicator

Mobile for Windows clients




7/19/2010 TechNet Blogs

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

All the information used in the queries resides on these databases. To execute the queries, I’ll use Microsoft

SQL Server Management Studio (actually I’ll 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, we’ll 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:



SELECT DISTINCT r.UserAtHost FROM RTC.dbo.Contact c INNER JOIN

RTC.dbo.Resource r ON c.OwnerId = r.ResourceId

And here’s 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 I’ll 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:



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



“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.


Dude, Where’s my CDR/Archiving/QoE Data?Wed, Jun 16 2010 by ucspotting

0

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) Backend. 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-ARCH-

MON\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 TokenGroupsGlobalAndUniversal

attribute of the sender's user object. Only users with domain administration permissions can add members



to the Windows Authorization Access Group, which is allowed access to the

TokenGroupsGlobalAndUniversal attribute, in one of two ways:

1) For best security practice, add only the computer accounts that need access to the

TokenGroupsGlobalAndUniversal 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 TokenGroupsGlobalAndUniversal 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).



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.


How to apply updates for OCSThu, Nov 26 2009 by ucspotting

0

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 it’s 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, it’s 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:



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 I’m 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.



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 OCS2009-

DBUpgrade.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 don’t recommend but that I’ll 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



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 João 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.


Tales from the Crypt..oAPI Vulnerability (KB974571)Thu, Oct 15 2009 by ucspotting

2

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 you’re superstitious, religious or a devoted fan of Murphy Laws, the naked truth is that sh*t



happens! And that’s 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.



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



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.



“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 known 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”.


Live Meeting: Best Before Date (See Below)Fri, Aug 14 2009 by ucspotting

1

Although on-premises web conferencing meetings organized with Office Communications Server (OCS) are

not perishable products (and thus they don’t require a “best-before date”), there is some configuration

involved around meeting life-cycle that I would like to explore a little bit further.



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, let’s 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, it’s no longer possible to rejoin the conference, unless it’s 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 can’t 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 it’s not possible to control the duration of the meeting expiration period



(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, it’s 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:



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.

'

' ContentExpirationGracePeriod

'

Dim objLocator

Dim objService

Dim objInstances

Dim objInstance

Wscript.Echo "Connecting to local WMI store..."

Set objLocator = CreateObject("WbemScripting.SWbemLocator")

Set objService = objLocator.ConnectServer(".", "root\cimv2")

Wscript.Echo "select * from MSFT_SIPDataMCUCapabilitySetting"

Set objInstances = objService.ExecQuery _

("select * from MSFT_SIPDataMCUCapabilitySetting where backend=""(local)\\rtc""")

' For OCS Enterprise Edition: backend=""server name\\sql instance""

If IsNull(objInstances) Or (objInstances.Count = 0) Then

Wscript.Echo "Error: No instance"

Else

For Each objInstance in objInstances

objInstance.Properties_.Item("ContentExpirationGracePeriod").Value = 365

objInstance.Put_

wscript.Echo objInstance.Properties_.Item("ContentExpirationGracePeriod").Value

wscript.Echo "Done!"

Exit For

Next

End If

Wscript.Echo ""

' MaxMeetingLength

'

Dim objLocator

Dim objService

Dim objInstances

Dim objInstance

Wscript.Echo "Connecting to local WMI store..."

Set objLocator = CreateObject("WbemScripting.SWbemLocator")



Set objService = objLocator.ConnectServer(".", "root\cimv2")

Wscript.Echo "select * from MSFT_SIPMeetingScheduleSetting"

Set objInstances = objService.ExecQuery _

("select * from MSFT_SIPMeetingScheduleSetting where backend=""(local)\\rtc""")

' For OCS Enterprise Edition: backend=""server name\\sql instance""

If IsNull(objInstances) Or (objInstances.Count = 0) Then

Wscript.Echo "Error: No instance"

Else

For Each objInstance in objInstances

objInstance.Properties_.Item("MaxMeetingLength").Value = 8760

objInstance.Put_

wscript.Echo objInstance.Properties_.Item("MaxMeetingLength").Value

wscript.Echo "Done!"

Exit For

Next

End If

Wscript.Echo ""

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 backend="server name\\sql instance"

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



1 2 3 4 5

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.



TechNet Blogs1

Documents

Transcript of TechNet Blogs1