Forgive my enthusiasm, but sometimes we can’t help feeling amazed by the creativity and passion some people put into their work.

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

Recently I had the opportunity of participating in a Pilot of Lync Server in a customer that has the internal network segregated by firewalls. So, one of the first questions was about the ports and protocols used by Lync Server.

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.