Mino – The UC Guy

Microsoft Unified Communications Blog

Archive for the ‘Uncategorized’ Category

Microsoft UC vs Cisco UC

Posted by Mino on October 31, 2010

Advertisements

Posted in Uncategorized | 8 Comments »

Lync 2010 Collocated Mediation Server vs. Dedicated Mediation Server

Posted by Mino on October 11, 2010

Learn why we should collocate or not collocate Mediation Servers onto Front End Servers in Microsoft Lync Server 2010.

via Lync 2010 Collocated Mediation Server vs. Dedicated Mediation Server.

Posted in Uncategorized | Leave a Comment »

Communicator for Mac 2011 Deployment Guide

Posted by Mino on October 8, 2010

From the Blog of Jonathan McKinney

https://www.t2mdev.com/jonmck/Lists/Posts/Post.aspx?ID=13

Features Available

  • Calendar based presence
  • Presence in other Office for Mac applications
  • Outlook Out of office messages in Mac Communicator
  • Invite multiple people to conference
  • Join conf: meetings from an outlook Invite
  • Enterprise Voice supported
  • OCS 2007 R2 support (OCS 2007 RTM is not)

Not available

  • Access Level for Contacts
  • Call forwarding
  • Receiving calls on mobile devices
  • Voicemail access from Mac Communicator
  • Scheduling of conferences in Outlook
  • Desktop sharing
  • No mention of Live Meeting

I am extremely pleased with the progress the Mac Communicator team has made. I expect the user experience with Lync to fill in some of the holes above with the Reach client. Finally, the Mac user can join the rest of the Unified Communications fun!

Here is the link to the Mac Communicator Deployment Guide. Enjoy!

Posted in Uncategorized | 3 Comments »

Lync 2010 Address Book Normalization

Posted by Mino on October 1, 2010

As always, a perfectly written and extremely valuable post by the MVP Jeff Schertz , such great posts put a wide smile on my face 🙂 Great work Jeff.

http://blog.schertz.name/2010/09/lync-2010-address-book-normalization/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+jschertz+(Jeff+Schertz)

As discussed in a past article the Address Book Normalization process of OCS is a barely-documented and often misunderstood process.  The objective of this blog article is to explain how this process works now in Lync Server 2010.

Overall the process is generally the same, but with a few minor changes that impact both how it is configured and how normalization functions.

Default Behavior

Firstly, just as in previous versions of the client any telephone numbers stored in Active Directory phone attributes directly in RFC3966 complaint formats (+E.164) will be displayed by the Lync Client.  The number will appear both on the contact call menu and the contact card details.  For example the pattern +13125557501 is populated on the following AD user account and appears in Lync.

1

Secondly, following the same basic principals of previous versions the Lync client will also not display any phone numbers on contacts which fail to normalize into a +E.164 pattern.  For example the pattern (312) 555-7505 is populated on the following AD user account and does not appear in Lync.

2

In order to display number formats in the second example Lync Server will need to be manually configured to properly normalize these numbers.  As a general best practice the format should be pretty uniform among all AD users and contacts but if they are not then multiple rules can be added to match and normalize various numbering formats.

Configuring Address Book Normalization

By default normalization is already enabled in Lync Server which can be verified by the viewing the Lync Server’s current Address Book configuration.

  • From the Lync Server Management Shell execute the cmdlet Get-CsAddressBookConfiguration and note that theUseNormalizationRules value should already be set to True.

3

But this setting in and of itself does nothing yet as the normalization file needs to be configured first.  Just as with OCS the Address Book does not leverage any Enterprise Voice normalization patterns which may have been created to support EV calling.  Note that if the value is set to ‘False’ (Set-CsAddressBook –UseNormalizationRules $false) then even numbers already entered in +E.164 format will not appear in the Lync client.

  • Locate the Lync Server’s shared directory which was configured during the initial server deployment.  The file server FQDN and share name can be identified in the Topology Builder under File Stores

4

Browse to the share directory on the server and locate the ABFiles subdirectory.

\\lab1ls\LyncShare\1-WebServices-1\ABFiles

Create a new text file named Company_Phone_Number_Normalization_Rules.txt in the ABFiles directory.  This normalization rules file must be stored in this location and not down a few directories where the actual address book files are stored as it was in OCS.

5

Edit the file with Notepad and enter the following example normalization and translation patterns.  This rule will apply to  the users configured with phone numbers in this standard 10-digit format: (312) 555-7500.  (The first three lines are commented out and are not required in the text file.)

6

 

Up until this point anyone familiar with Office Communications Server should recognize that everything is about the same, other than the required location of the normalization text file.  An improvement in Lync Server’s address book normalization process is instantly noticeable when looking at the simplicity of the example pattern above.  In the past long, complicated regular expressions (regex) were required to filter-out any non-digit information which could be potentially stored in the telephone field.

But now Lync Server automatically ignores non-telephony related digits in the strings and only looks at the continuous 0-9 numerical digits (and also recognizes the + symbol).  So there is no longer a need to include regex code like [\s()\-\./]* in patterns to ignore spaces, parenthesis, dashes, etc.

  • Execute Update-CsAddressBook to import the new settings configured in the text file and apply them to numbers stored in the address book files.

7

At this point the contacts previously not displaying phone number information should now be working.

8

Posted in Uncategorized | 2 Comments »

OCS / Lync Server Normalization Rules

Posted by Mino on September 30, 2010

This is a very good post by Jonathan McKinney about Normalization Rules , what I loved in it is the simplicity of explanation. Please appreciate this post young folks , we learnt it the hard way by practice and projects because there was no one to explain it to us this way 🙂

Thanks Jonathan https://www.t2mdev.com/jonmck/Lists/Posts/Post.aspx?ID=6

When normalization rules were first explained to me in an Office Communications Server 2007 training class, I left thoroughly confused.

I spent quite a lot of time trying to understand how normalization rules work. First, I found that normalization rules are .Net Expressions. A quick search of the Internet for .Net Expression primers and help guides did not help with understanding how they worked.

I finally found a piece of software called RegEx Designer that allowed me to see what is happening in a .Net expression and more importantly a normalization rule.

Let’s start with why we need telephone numbers (straight from the IETF/ITU standards).

  1. A telephone number is a string of decimal digits that uniquely indicates the network termination point.

  2. The number contains the information necessary to route the call to the termination point.

A Normalization Rule modifies the user input and presents a fully routable telephone number that can be used by Office Communications Server (OCS) / Lync Server and the PSTN to delivery a voice call to the intended termination point. To OCS / Lync Server, your telephone number is effectively meaningless if it is not presented in E.164 format.

Humans are inconsistent, especially with how we write phone numbers down. People use parens, dashes, dots, and spaces for example. Users in a business might only know a 4 digit extension to call another employee. Normalization Rules help the humans enter the phone number in the format they are used to and then translate that to the pattern that OCS / Lync Server is expecting.

There are three main processes happening when a normalization rule is used.

  1. Does the Phone Pattern Regular Expression match the input?

  2. What is captured in the Phone Pattern Regular Expression to be used by the Translation Pattern Regular Expression?

  3. What is the Translated number?

Example Normalization Rule

Phone Pattern Regular Expression: ^(2\d\d\d)$
Translation Pattern Regular Expression: +1425555$1

The "^" specifies that the match must occur at the beginning of the string.

Anything between parens is captured into a group. If there are more than one set of parens then there are multiple groups.

Any letter that is after "\" is considered a language element and has a special function. For example \d is a single digit wildcard. \D is a single character wild card.

"$" Specifies that the match must occur at the end of the string.

In the above example we are matching against any 4 digit number that starts with a 2. We are capturing the 2 into group 1 plus any other 3 digits that follow. If a number is 5 digits it will not match. If a number starts with any other number than 2 it will not match.

Now that we have captured group 1 we can take a look at the Translated Pattern Regular Expression

Phone Pattern Regular Expression: ^(2\d\d\d)$
Translation Pattern Regular Expression: +1425555$1

The +1425555 are absolute digits and will be inserted before the captured digits in group 1 "$1". Each group is represented by a $ and a digit for the order in which they were captured. The second group captured would have a "$2" in the Translation Pattern Regular Expression.

If we entered 2345 then the translated pattern would be +1425552345.

What if we wanted to match against 5 digits and only capture 4 for example?

Phone Pattern Regular Expression: ^6(\d\d\d\d)$
Translation Pattern Regular Expression: +1425555$1

The above rule would match any 5 digit number that started with a 6. But, because the 6 is not within the Parens we will not capture the 6 into group 1.

If we entered 62345 then the translated pattern would be +1425552345.

Is there an easier way to specify multiple digits rather than writing\d\d\d\d?

Phone Pattern Regular Expression: ^6(\d\d\d\d)$
Translation Pattern Regular Expression: +1425555$1

is the same as

Phone Pattern Regular Expression: ^6(\d{4})$
Translation Pattern Regular Expression: +1425555$1

The {x} specifies the number of matches for the preceding Language Element. In this case we are looking for 4 digits. If I specified \D{4} then it would be 4 characters.

If we entered 62345 then the translated pattern would be +1425552345.

What does a normalization rule look like capturing multiple groups of numbers?

Phone Pattern Regular Expression: ^(\d{3})(\d{4})$
Translation Pattern Regular Expression: +1425$1$2

In the above Phone Pattern there are two sets of parens. Each set of parens captures into a different group. The first three digits are captured into group 1 "$1" and the next 4 digits are captured into group 2 "$2".

In the Translation Pattern we use $1 and $2 after the +1425.

If we entered 5552345 then the translated pattern would be +1425552345.

What if we wanted to handle dashes, spaces, dots, and whatever else users dream up?

Phone Pattern Regular Expression: ^(\d{3})\D(\d{3})\D(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3

In the Phone Pattern Regular Expression we are matching for 3 digits, then a single character. Then another three digits, and a single character. Then a final four digits. Since the \D is not within the parens we match against it, but are not capturing it. The result is the Translation Pattern has no dashes, dots, spaces, or any other character the user can dream up.

If we entered 425-555-2345 or 425.555.2345 then the translated pattern would be +1425552345.

Why do you use \D instead of [\s()\-\./] ?

Simple. It does the same thing and more! \D will match any non-digit. [\s()\-\./] will only match space, parens, dash or dots.

Is there a way to do optional matches?

Phone Pattern Regular Expression: ^9?(\d{3})\D(\d{3})\D(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3

In the Phone Pattern Regular Expression above we start of with a "9?". This means the expression will match if there is a 9 or not a 9. The key is using the question mark after the number (or character). This is handy if you want to be allow users to still dial a 9 like they used to on a PBX. They can type it in or not, we simply don’t care because it is optional and we are not capturing that digit into a group.

If we entered 9425-555-2345 or 425-555-2345 then the translated pattern would be +1425552345.

How would I do a wild card for any number of characters/digits?

Phone Pattern Regular Expression: ^\D*(\d{3})\D*(\d{3})\D*(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3

The above Phone Pattern Regular Expression will look for any amount of characters until it matches against 3 digits. Then any amount of characters until it matches against another 3 digits. Then a match against the last four digits.

The benefit of this is that we can handle "(425) 555-1234" or "425-555-1234" or "4255551234" and to be honest we can handle this too "Your grandma 425 has white 555 hair 1234". All the examples would be translated to +14255551234

How about logical OR?

Phone Pattern Regular Expression: ^\D*(303|720)\D*(\d{3})\D*(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3

A logical OR is very handy if you need to handle multiple area codes, or NXXs (the second set of 3 digits for non-voice people). The pipe sign is what does the logical OR within the parens. The above Phone Pattern Regular Expression would look to match the first three digits to 303 or 720, but not both.

If we entered 303-555-2345 or (720) 555-2345 then the translated pattern would be either +1303552345 or +17205552345.

Conclusion

In my experience the above examples will help with 90% of the needs for Normalization Rules. There are much more complicated Normalization Rules that could be written, but I’ll leave that to another post. If you want to play around with Normalization Rules I strongly encourage downloading RegEx Designer so that you can visibly see how Normalization Rules work.

Posted in Uncategorized | 6 Comments »

You may encounter problems when you use the Absconfig.exe tool

Posted by Mino on February 2, 2010

When you install OCS 2007 RTM resource kit and you try to run the ABSconfig.exe, you get the below error

ABS Configuration Tool -Error
Exception: System.ArgumentOutofRangeException: Value of ‘6/17/2008 6:30 AM’ is not valid for Value.  Value should be between ‘MinDate’ and ‘MaxDate’.  
Parameter name: Value

at System.Windows.Forms.DateTimePicker.set_Value(DateTimeValue)

at ABSConfig.MainForm.WMIConfigInit().

and then also you get the error  :ABS is not enabled or activated on this server (to enable set the WMI outputlocation to null)

The problem is explained in the KB Article 954749  and Hotfix for the ABSConfig.exe is available for download.

Posted in Common Errors, OCS Tools Kit, Uncategorized | Tagged: , , , , | Leave a Comment »

How to get save password option for Office Communicator users

Posted by Mino on May 24, 2009

Open Registry editor and locate the following key:

HKLM/Software/Policies/Microsoft/Communicator,  and set SavePassword=1.  

This enables a checkbox to save password in MOC login dialogue.

After the password is entered it is saved into the registry

HKCU/Software/Microsoft/Communicator/AccountPassword

This registry key store in hashed value. Changing the hash requires re-entering the password.

Note: You may want to use this option if MOC users login from workgroup machine, or Kerberos authentication is not working

Source :http://www.ocspedia.com/FE/How_to_Save_Password_MOC.htm

Posted in communicator client, OCS 2007 R2, Uncategorized | Tagged: , , , , , | 3 Comments »

OCS 2007 R2 Server Loses network connection on Server Startup

Posted by Mino on May 13, 2009

As strange as this might sound to you but this is the latest case I have faced which in the end appeared to be a known bug and Microsoft Premiere Support were able to solve it after 3 weeks of investigation

Setup

So you have OCS 2007 R2 implemented over Windows 2008 and the Backend is placed on SQL 2008 on windows 2008 server. The below roles are all implemented on windows 2008:

  • Front End 1
  • Front End 2
  • Mediation
  • Consolidated Edge not joined to the domain

Problem:

When you restart any OCS server you cannot remote access to that server again, the Ping over the server is lost and when you go and check the server you find the network is disconnected.

If you went through all of the OCS Server services you will find them all are in the mood of starting and it will take it like 10 minutes then it will fail to start .

If you set these OCS Services to manual start rather than Automatic then reboot. You will find that the server is functioning normally.

This is really a very strange problem and I never faced it before as I have already implemented the OCS on 2008 but I still up to this moment don’t know the symptoms that causes this problem to happen.

Solution:

– Set startup type for wmiApSrv to automatic

– Add dependency on RtcSrv to wmiApSrv

– Set startup type for RtcSrv to automatic

– Reboot

– RtcSrv is starting and running

– Set startup type for all Rtc* services to automatic

– Reboot

– All Rtc* services starting and running

 

To set the RTCSrv service dependency you can use the registry to modify the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RtcSrv and modify the DependOnService to include the wmiApSrv.

Posted in Consolidated Edge, Edge Server, Front End Server, Miscellaneous, OCS 2007 Components, OCS 2007 R2, Uncategorized | Tagged: , , , , , | 8 Comments »

The Sixth Sense Tech of the Future ( Must Watch )

Posted by Mino on March 30, 2009

Posted in Uncategorized | Leave a Comment »

Customizing Exchange UM Auto Attendant

Posted by Mino on March 24, 2009

 When you normally configure your Exchange UM auto attendant, here is the normal greeting that you will hear:

“Welcome to the Exchange Auto Attendant. Use the key pad to spell the name of the person you are calling, last name first, or to spell their e-mail alias, press the # key twice. If you know the extension, press the # key.”

One of our clients requested to change the Auto Attendant to give him in the end the below experience:

“Welcome to Company ABC, please dial the extension of person you are calling”

Which means that we need to remove the following parts from the Greeting:

·         Name lookup

·         The # key

In the end this was done by the below command from the exchange shell and of course we used a custom greeting for the first custom welcome part.

Set-UMAutoAttendant -Identity “test” –NameLookupEnabled $false

Replace “test” with the name of your Auto Attendant

Also the client asked if that greeting can be interrupted , we tested that and it appeared that it can only be interrupted after the first wav file ends which is “ welcome to the exchange auto attendant “  .

If you tried to interrupt before this greeting ends then you will hear a sorry message , however you can enter any digits and interrupt the greeting right after that 3 seconds part. 

Posted in OCS & Exchange07, Uncategorized | Tagged: , , , , , , , , , | 1 Comment »