Registration is LIVE for Lync Conference 2014.

Microsoft Lync Conference is the largest global Lync event giving you access to the top Lync product experts and partners in the world.

We're excited to announce that REGISTRATION IS LIVE for Lync Conference 2014 at www.lyncconf.com!

Lync Conference is coming to Las Vegas on February 18, 2014 at the Aria Resort & Casino in the heart of the Las Vegas Strip. We are keeping you in mind as we approach Lync Conference 2014 where you'll hear Lync content from around the world. The Keynote will give you a sneak peek at Microsoft's vision for the future of Unified Communications, and the breakout sessions will offer you a technical and business perspective of Lync and how it can impact your business every day.

The worldwide Lync Conference is back.

Be the first to register today!

This is a small marketing video about Windows 8, made in Portugal, that shows how surprisingly simple it is to work (and have fun) with this new operating system.

“Is Windows 8 really that simple? Find out the answer in a surprisingly simple stunt that took place in December 7th, in a Fnac store in Lisbon. The moment speaks for itself.”

The requirements of this pilot included:

• Co-existence with OCS 2007 R2
• Exchange 2010 Unified Messaging
• External Access
• Integration with existing video-conference infrastructure
• All the UC workloads

The ports and protocols used by Lync are pretty well documented in the following TechNet pages:

• Ports and Protocols for Internal Servers
• Reference Architecture 1: Port Summary for Single Consolidated Edge

Additionally, the Microsoft Lync Server 2010 Protocol Workloads Poster does a very good job illustrating not only the ports and protocols used by each UC workload, but also their dependencies and relationships.

Instead of letting the customer compile and aggregate all the provided technical information, we decided to provide some Visio drawings, in order to facilitate the configuration tasks of the security team. In the end we delivered the following schematics:

Please note that these were built for a pilot and not for a Production environment, thus minor errors/inconsistencies may have been depicted. If you find one, please let me know.

If you want the Visio document, it can be downloaded here.

This is what I like to call a “Jurassic post”. Now that Lync is widely available, it’s uncool to still blog about OCS 2007 R2 :-)

But since there are still so many organizations using OCS 2007 R2 (I’m sure they all have plans to migrate to Lync) I decided to blog about one of the most common requests I (used to) get: how to normalize company rules without the plus sign?

Let me tell you that I recommend full E.164 normalization throughout all the OCS configuration settings. Nevertheless, I understand that user experience is a key factor for a success deployment, thus, if people are used to dial “0” to get an outside line and if they never used the “+” sign, that could be a good reason to configure similar normalization rules.

Another reason could be the fact that the legacy PBX is also configured that way, “0” for outside lines and no “+” signs accepted. Instead of configuring additional translation rules, we can make OCS provide the expected number configuration.

So, imagine our fictitious company Contoso, which has a location profile HQ.contoso.com.

This location profile has 2 normalization rules, one for internal extensions (6-digit) and another one for external numbers (9-digit):

If a user on Communicator dials any of these number patterns, the translation result will still look familiar, much like what he/she has used his/her entire life:

But besides the normalization rules from the location profile there is also the company normalization rules that convert the numbers stored in Active Directory. This set of translation rules is defined on the Company_Phone_Number_Normalization_Rules.txt file, stored on the Address Book share (more information at Configuring Address Book Server Phone Normalization).

The problem with configuring translation rules that don’t include the “+” sign is that they are not E.164 compliant, thus OCS will not import those numbers into the Address Book. So, what’s the trick? The trick is to prepend to the translation pattern “;phone-context=<location profile>”.

Here’s what the rules might like in our example:

(\d{9})
0$1;phone-context=HQ.contoso.com

(\d{6})
$1;phone-context=HQ.contoso.com

Let’s take a look at the properties of the user Administrator in Active Directory:

Notice the numbers all have 9-digit because they represent outside lines. With the previous rules on the Company_Phone_Number_Normalization_Rules.txt file, when the OCS Address Book service runs it will translate them appropriately and showing them to users as expected, as depicted in the following picture:

By opening the local GalContacts.db file on the user’s computer, we can confirm that the translation rule was applied.

And now the good news: this “trick” also works with Lync Server 2010. But beware with the changes regarding the translation patterns, certain type of expressions no longer work with Lync. For more information read Migrate Address Book.

Dialing authorization is definitely one of the main concerns of any PBX Administrator, maybe even more now that the economy is forcing most companies to reduce costs.

Since Office Communications Server (OCS) 2007 R2 has all the necessary telephony capabilities to replace the PBX, it should offer the same dialing control as those legacy PBX’s… And it does!

Before diving into further detail, let’s first introduce some terminology and concepts associated with OCS:

In order to define different levels of dialing privileges, we must create different Voice Policies (that must be assigned to the different users), which in turn control the access to the outbound Routes. And in the end, it’s all about the Routes, Routes act as the Checkpoint Charlie of outbound calls: if a user is configured with a Voice Policy, that contains a certain Phone Usage, that is associated with a Route for the dialed number, then the call is successfully placed.

Confused? I’ll give you an example shortly, but before, take a look at this diagram from Microsoft TechNet site User Authorization and Outbound Call Routing Requirements:

A practical example

From my field experience, I noticed there is more or less a pattern from all my customers regarding the types of outbound call privileges, which is:

• Internal Extensions – These kind of users can only place calls to internal extensions.
• National Land Lines – Users with this policy defined may dial internal extensions and national land lines.
• National Mobile Numbers – These will be the users allowed to dial the previous type of numbers plus national mobile phones.
• International Numbers – For those users who need to place international calls, as well as national, of course, this will be the appropriate level of authorization. This policy doesn’t allow dialing value added numbers.
• All Calls – The lucky ones assigned with this level of authorization may dial any number they want.

This simple practical example will cover a single location with a single point of exit to the PSTN. It will be relatively easy to derivate from this sample example and build more complex scenarios.

If you noticed the above diagram, the first step is to define the location profile(s) and to configure normalization rules, which I won’t cover in this post (if you want to know the details, please read Location Profiles and Normalization Rules).

So I’ll start instead from the Phone Usage Records definition. The picture below depicts the 5 phone usage records created in this practical example, one for each of the outbound calling privileges described previously.

The next step is to create the corresponding voice policies. Once again there is a voice policy for each of the phone usage created previously, as depicted in the following picture:

Notice that Use per user policy is selected, as opposed to selecting a default global policy, since we want to differentiate the privileges each user has.

Since the users with more dial out privileges must also be able to place less privileged calls (users allowed to dial mobile numbers can also dial internal extensions, for example), the more “advanced” policies must include the less privileged phone usages, as the following pictures illustrate.

The final step is to create the voice routes, and once again, there will be one route for each phone usage, plus one for the emergency number. The following table provides a brief explanation of the different routes configured:

Here’s an image of the Routes tab from the OCS Voice Properties dialog box:

Each route has only the corresponding phone usage associated, except the emergency route, which has all the configured phone usages, as illustrated below:

Testing and validation

Now that everything is in place, we need to test if the different configured user profiles work as expected. There is a neat tool, part of the Microsoft Office Communications Server 2007 Resource Kit Tools that really suits this task: Enterprise Voice Route Helper. For detailed instructions on how to use the tool, there is a comprehensive user’s guide available to download.

All the different combinations between voice policies and the different possible outbound numbers should be tested, but for demonstration purposes I’ll use only 2 test cases:

1. A user with the Default Policy dials the emergency number
2. A user with international call privileges dials a value added number

For the first scenario the call is permitted and routed out, as you can see in the following picture:

As for the second test case, the call is blocked, with the message “Unable to route”.

Recommended reading

For more details regarding Enterprise Voice planning and configuration, please read the following technical information from the TechNet site:

• Walkthrough: Dial Plan Configuration
• Enterprise Voice Support
• Blocking Calls to Certain Destination Numbers

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:

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

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.

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.

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.

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]

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

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