What's in a name? That which we call the Edge...

I recently deployed CAC on Lync for a customer. There was a large number of sites, but they had kept AD up to date and the information was in a format we could use to define all the sites in Lync. So I exported it to a CSV, dusted off my Excel skills, and had half the info I needed to complete my task. I then worked with the Network Gods to determine how much bandwidth they could spare for Lync traffic. A quick design document and a slide deck or two to explain what we were doing and we were ready to go.
So our change request was approved, I had all the info I needed and soon the change window rolled around. I created the polices we needed, created the sites, imported the subnets it was a text book implementation. The only problem was that no one was around to test, but never mind how could anything have gone wrong?
The next morning I eagerly checked the Lync CAC report but it wasn't reporting anything, maybe no calls had been blocked yet I thought. I then opened up the Bandwidth Policy Monitoring Tool and there was nothing going on. I then made some test calls and still couldn't see anything. It was time to get into the Logging Tool to see what was going on.
It turns out that when the Edge Server was defined in the topology and installed the FQDN was not used. For some reason, Federation, PIC and Remote Access were all working without and issue but CAC was unhappy.
To resolve this, I just had to include the Primary DNS Suffix on the Computer Name settings of the Edge server and reconfigure the Edge server in the Lync Topology. I then needed to rerun the install on the Edge which actually uninstalled the Lync software (because the server name was no longer in the topology) and then reexport the topology and reinstall the Edge.
After all this CAC was working perfectly and the only problem that was experienced was some unhappy campers in sites that had insufficient bandwidth and consequently were unable to make calls.

So for Matt's 5 cents:
Always use the FQDN when defining your Edge Servers in the Topology. The Edge server (if you have one) plays a critical role in CAC working correctly thanks to ICE. If you're having trouble sleeping and would like to know more, you can read this article which explains how this is all hanging together http://msdn.microsoft.com/en-us/library/ff595756.aspx.

Can Lync improve your life?

I don't need to reiterate how the technology that Lync brings to the table can have an impact on our work lives. Never have I appreciated this more than when I found out how through Lync I had been a small part in helping two hearing impaired users that work with one of my customers.

The first of these experiences was finding out that a lady was now able to lip read using video on Lync. We had just given webcams and headsets to an entire business unit that this lady was part of as a pilot and this was part of the feedback that we recieved. Needless to say I was pretty happy to be part of that.
The second was a little more challening to get sorted but equally rewarding. I learnt that in Australia we have a National Relay Service (http://www.relayservice.com.au/). These guys are worth their weight in gold. Basically they have a feature where someone can use MSN Messenger or Yahoo to communitate à la TTY, without needing any specialised hardware. Only problem was that MSN Messenger is frowned upon by this corporate, so we were asked how we could get this to work with Lync.
We were able to enable PIC and then have the user add the contact nrsiprelay(iprelay.com.au)@msn.com. After some help from the National Relay Service Helpdesk our user was in business and able to make calls.

So for Matt's 5 cents:
When discussing Lync with your customers, don't forget to mention that it is possible enable services such as these. You never know how much impact it could have.

One Good Reason to use UAG

Ever since the release of TMG and UAG I have been trying to work out what is there best product to use if I just want to publish Exchange stuff such as OWA, ActiveSync and Outlook Anywhere. Well I have finally found the answer. Quite a number of companies are worried that publishing these services will create an opportunity for hackers to lock their users accounts simply by attempting to access these services and providing the right username with the wrong password. I agree that the risk is probably not that big but it is there never the less. Certificate based authentication is one way to get around this but brings about its own challenges such as the TMG/ISA server needing to be a member of the domain.

After some testing I also found out that TMG tries to authenticate the user before deciding if the user is even allowed to access the services. This means that if you have used a group or create a "User Group" on TMG to limit the users that can use these services, you are still faced with the risk that your entire organisation is still at risk from this kind of attack.

Thankfully UAG has something to help combat this. UAG has an option that holds off further authentication attempts for a configurable amount of time when a threshold has been reached. For example, an administrator can say that after 3 incorrect logon attempts the user is held off for 60 minutes. Obviously you need to take into consideration your current password polices to ensure you have the optimal configuration.

Another thing I learnt the hard way is that UAG by default requires access to your CA's CRL and if it cannot get to it will provide your users with a generic Certificate Error message. To modify this behaviour you need to change the HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\URLFilter\Comm\SSL\ValidateRwsCertCRL value to 0.

I also found this whitepaper (http://go.microsoft.com/fwlink/?LinkId=197136) from Microsoft that outlines Publishing Exchange Services with both TMG and UAG and also includes some intersting info that you can use to work out which product will best meet your needs.


So for Matt's 5 cents:
UAG has some cool features that are not well documented. If security is a major concern and you require the ability to set a more comprehensive policy then UAG is for you. A word of warning though, for those of you that are familiar with TMG, UAG is a totally different look and feel and it is a bit more complicated.

iPhone: Friend or Foe

From the many articles that have been circulating around the iPhone and Microsoft employees it would seem that Microsoft views the iPhone as an enemy. Windows mobile (pre version 7 of course) seemed like a great platform that was until the iPhone came out and we saw (myself included) people change their views of what Windows Mobile could offer. A comparison between the two was like comparing NT4 Workstation with Windows 7. So what did Microsoft really expect? It seems like the only people left using Windows Mobiles are Microsoft employees and people who had been given the device as a work mobile. Don't believe me, next time you are in a meeting ask everyone to show you what they are carrying around.
So let me get to my point. Microsoft claimed that Windows Mobile coupled with Exchange ActiveSync was going to be a Blackberry killer. A few years later and this is still as far away as ever from being a reality… Enter the iPhone. We are now seeing that even C levels are starting to ask when they can connect their iPhone to Exchange and also even seeing some corporates adopting and handing out the iPhone as a standard device. This is easy to achieve by leveraging the ActiveSync protocol that Apple have licensed and allowing users
But how do you get around the issues that have been talked about around security. The easiest and cheapest way is to ensure you have a solid ActiveSync Policy. Here are some of the key settings that should be considered:

•  Allow Non Provisionable Devices - This setting ensures that only devices that are able to apply ActiveSync polices are able to connect. If you enforce device encryption an iPhone 3G running OS 3.x and later (there is a bug in earlier versions that falsely reported to Exchange that the device supported hardware encryption) will not be able to connect.
• Enforce password on device – This setting ensures that all users of ActiveSync have a password/pin protecting their device.
• Maximum failed password attempts – In case a device is lost or stolen, this setting ensures that the device is completely wiped after the maximum number of attempts to gain access to the device has been exceeded. This setting needs to be thought out carefully as too few attempts means that users may end up wiping their devices accidently and too many gives attackers a greater chance to gain access to corporate data.
• Inactivity time in minutes – Another setting that needs to be thought out carefully, too short a setting can be frustrating to users if the password requirements are complicated and too long can result in increased risk of unauthorised access to data.
• Minimum password length – This setting can cause a great deal of pain in terms of usability. The right balance between minimum password length, Inactivity time and Maximum failed password attempts is key to having happy users.

When building your ActiveSync policy keep in mind that only a subset of the available policies, listed below are supported by iPhones:
• Remote wipe
• Enforce password on device
• Minimum password length
• Maximum failed password attempts (before local wipe)
• Require both numbers and letters
• Inactivity time in minutes (1 to 60 minutes)
• Allow or prohibit simple password
• Password expiration
• Password history
• Policy refresh interval
• Minimum number of complex characters in password
• Require manual syncing while roaming
• Allow camera

So for Matt’s 5 cents:
The iPhone is proving to be a catalyst for people to move towards ActiveSync as a mobile messaging platform. While planning for iPhone access to ActiveSync don’t forget that your ActiveSync policy really needs to cater for all ActiveSync users regardless of device type. So even though the iPhone policy support is limited you should still ensure that the other settings are still suitable for those people with Windows Mobile or Android devices.

What is going on with Wave “14”

If you are like me you are itching to find out what Microsoft is going to do around Wave 14. VoiceCon has come and gone and Microsoft have had the CS14 Airlift (so there is the first thing that has changed, the name). So far there are only a few places where you can publicly get some hints as to what is coming.
The first thing to check out is Microsoft’s response to the VoiceCon RFP. As Microsoft is using Wave 14 to reply it is a great place to start to see what is new in the Voice space.
http://download.microsoft.com/download/B/9/3/B939AA7C-AB08-49E2-B85D-136EDDAF4071/RFP%20-%20IP%20Telephony%20System.xps
Another thing to checkout are some videos from TechDays 2010 in Europe where François Doremieux demos some of the new capabilities that are on the way.
http://edge.technet.com/Media/TechDays-2010-Introduction-to-Microsoft-Communications-Server-ldquoW14rdquo/
http://edge.technet.com/Media/TechDays-2010-New-Voice-capabilities-and-infrastructure-in-Microsoft-Communications-Server-W14/
It seems that the message that Microsoft is sending with this release is that they have pimped up their Voice offering sufficiently that they will now be able to compete mano-a-mano against the traditional players.

So for Matt’s 5 cents:
Watch this space closely. More information is sure to trickle out from Microsoft as the release date draws closer. If you are about to make any investments around voice, I would have a quick chat to Microsoft.

CUCiMOC, caveat emptor...

For those of you out there thinking about making your user's dreams come true with CUCiMOC, have a quick think about the following before you continue:

You are going to have to deploy a client to all of your workstations. Before you decide to do this, have a quick chat to your Systems Management guys. Depending on your environment, this may not happen as quickly or as easily as you think.

Many CUCM deployments have required a second implementation of Active Directory, due to AD admins refusing to put the required schema changes in the production environment. What does this mean for you? CUCiMOC uses the currently logged on users creds to access many services, such as retrieving voice mail. This means your user name and password must be the same in both domains. No problem right, just manually sync them. This will work, but what happens after 30 days when your password expires?

Check your dial plans... CUCiMOC will just dial the numbers you give it. One problem you may come across is that in your GAL, your numbers are probably in E164 format. Without modifications to your dial plan CUCiMOC won't be able to dial these numbers forcing you to manually modify numbers everytime you make a call.

It is not free. Depending on how you are licensed with Cisco will depend on how much this is going to cost you. Better do the maths up front.

Do you really want to strip your OCS deployment down to being just a presence engine? To make life less confusing for your users, Cisco  suggests that you hide all the native functionality of Communicator, leaving only the CUCiMOC calling controls exposed. Not sure this is really what you would have intended when you started on your OCS journey.

So for Matt's 5 cents:
CUCiMOC may be a good option for people who want to start using their PC as their voice endpoint but don't want to use Microsoft's UC platform yet. If you really think this is your only/best option, I would really suggest doing a pilot production with a handful of "real" users before jumping in, as some of these issues seriously impact user experience. For those who are unsure of how Microsoft's offering will compare, why not pilot that too, you may be pleasantly surprised. 

Cisco vs Microsoft. Who is telling the truth?

Over the last few days I have been listening to a lot of Cisco guys fresh from Networkers and sprouting all the latest anti-Microsoft propaganda. Here are some of the things that were given as ammunition to their followers.


1. The codecs used by Communicator are negotiated by the clients, unlike in the Cisco world, the codec is controlled by CUCM.
This is this is as the codec used by Communicator is adaptive, based on the amount of bandwidth between the clients. Obviously the OCS server is in no position to dictate this.


2. Integrating OCS with your Call Manager means you have to manage 2 dial plans, so keep it simple by using CUCiMOC.
In my experience it is easier to write up a dial plan in OCS than it is to deploy a client to thousands of machines. The one good thing about CUCiMOC, is that it does atleast start people getting used to using their PC as their Voice end point.

3. OCS has no CAC
I am not sure if I have ever picked up the phone and heard fast busy tone because my call was blocked by CAC. I think these days we have more issues with email clogging up links than we do voice. In any environment with or without CAC, if the network is not provisioned correctly you are going to have problems with everything you do not just voice.

4. Calls in a branch office will hair pin through Mediation Server
This scenario describes a situation where in a branch office, calls between Office Communicator and a Cisco phone will have to go from Communicator across the WAN to the Mediation Server and back down to the Cisco phone. This is true and would happen in an R2 environment (I have heard rumours that this will go away in 2010). I would however say that if you are migrating your voice platform to OCS that planning is key, and you would either have to migrate all or none in this situation.

5. Unity provides a richer user experience than Exchange 2007
The first problem with this statement is that Unity is built on Exchange (and not even the latest version). The issue most companies have with Unity is that it requires a schema extension. I have not yet seen a company that has put the Cisco schema extension into their production AD. So most implementations involve creating a second AD just for Telephony, giving them the flexibility they need to get the job done. This in turn means that users will now have 2 mailboxes. 1 for email and maybe fax/SMS and the other for voice mail. This means that you can only get real UM with a few paddle pop sticks and some sticky tape.

6. Microsoft UM requires a 3rd party for MWI
While this was true with Exchange 2007, this problem has now gone away. Exchange 2010 can natively switch that oh so important little red light on and off.

So for Matt's 5 Cents:
Both Cisco and Microsoft have great features and both have room for improvement. When looking at deploying UC, it is important to look holistically at the experience you are providing to your users, and keep your eyes on the road maps of your favourite vendors. This space is fast paced and ever-changing. Most importantly, to quote a hip hop group from the 90's, "Don't believe the hype".