This posting is provided "AS IS" with no warranties, and confers no rights.The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. Please use the Microsoft Forums for support requests.
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!
Register Here >
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:
The ports and protocols used by Lync are pretty well documented in the following TechNet pages:
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:
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:
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:
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:
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:
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”.
For more details regarding Enterprise Voice planning and configuration, please read the following technical information from the TechNet site: