Sunday, January 25, 2015

My views on what HoloLems means for Unified Communications

Warning... this is strictly an opinion piece with a lot of wishful thinking.

Wow... Microsoft dropped a bombshell on all of us with HoloLens. I spend a lot of time talking about technology with my kids (I have 5 in case you are wondering) and what the future could look like. I've been hoping for something like HoloLens for a very long time. I talk with my kids about how computing can be different, how user interfaces will change and what it could mean for how we interact with the world. Of course with kids you just have to give them that little push and their minds go crazy with possibilities because they don't know the boundaries that adults do.

One of my dreams is to be able to record every part of my real life and then be able to replay past events at will and have them projected via Augmented Reality into real life so I can see them again. Get to experience people from my past and see those little nuisances about them as humans that get lost in memories sometimes. I don't expect HoloLens to do this out of the box of course... but it is the first step in that direction.

My kids of course see completely different possibilities... it was a lot of fun to show them the video of the news briefing and to see them sucked in by the magic of the HoloLens technology... then the video showed a Minecraft like game that was being played in the real world and their little brains literally exploded. This was something they knew... but completely played in a different context.



Their brains exploded yet again when the video blew up a wall with Minecraft TNT and revealed a while world behind it with the wall becoming Minecraft blocks.



Suddenly they weren't limited to the Minecraft world that is finite... as one of my daughters put it... "I can build a castle in the backyard now (we have over 2 acres). See how they have no boundaries?

We went on to talk more about how it could be used, very excitedly I might add.

My oldest daughter asked "do you think I could design dresses for my sisters and see what they look like on them before I make them?"

Another daughter thought about her drama class and everyone having a HoloLens and being able to see their stage design and practice on the stage before it was even built.

My 15 yo son being a recent Star Trek fan (yes he watched all the seasons on Netflix... from the beginning) saw the possibility of Holodeck like experience but was quick to point out that the Holodeck can create real objects you can interact with... and not holograms.


But listening about my kids and their ideas about the HoloLens isn't why you pulled up my blog (although that may get me more visits)... 


Unified Communications and the HoloLens

When I saw HoloLens for the first time during the Windows 10 news briefing my mind was going crazy with what this means for Unified Communications. I think for many of us, we've been waiting for the "what is next" for Unified Communications and I believe HoloLens is it. Obviously Microsoft already sees it as a communications tool because they showed clips of it being used as such.

A woman walking through an office environment having a video conversation with a colleague who mentions uploading a file to OneDrive, then I assume what he uploaded becomes viewable to her instantly.




In another demonstration a woman is trying to fix a drain and again is having a video conversation, but now the person on the other end can draw indicators as to what to do that become holograms for the woman in her real life view.



In another view we see two people interacting with the surface of the planet Mars and the other person is represented as an avatar. They are both collaborating with the surface of Mars and indicating where they want to do the work.



We already know that Skype and Lync are sharing a lot of technologies, and the next version of Lync will be called Skype for Business. We also know that Microsoft is creating an Enterprise version of the HoloLens. So I think it is safe to assume that anything that the HoloLens can do with Consumer Skype will apply to Skype for Business.

HoloLens and the Skype for Business Call Center

One of the more exciting things that popped in my mind was a Consumer Skype calling a Skype for Business Call Center using HoloLens. Think about product support where it is really hard to describe your problem and even harder to tell someone the solution (like installing a light switch). How amazing would it be to see the problem, and then to be able to instruct using holograms as to what to change to fix the issue.

Obviously this could be killer for Help Desk applications, especially hardware issues. But I think more importantly, this would be a key use of the Skype-Lync Federation that Microsoft has been building on and recently added the ability to do Video. Consumer to Business communications is clearly something Microsoft has been trying to crack for a long time.

HoloLens and Skype for Business Meetings

I have a couple different visions for how it could be used.

First of all if we want to take the notion of how meetings are today in the Lync product, I can easily see being able to put different pieces of content/modalities all around your office, on different walls, floating in space in front of you. You won't be limited to the real estate of the computer screens to display all the different modalities. I think it would be really cool to move things around like minority report. Maybe if you want to upload a file from your PC, you look at it and then everything you've uploaded to OneDrive from that PC appears as an option. You literally grab the file using your hands and drag it over to the meeting.

I can also see meeting rooms setup to hold meetings where avatars represented by holograms appear in seats and the content appears in various places around the room. When someone speaks, the audio appears to come from that direction. With the ability for people to indicate with holograms what they are talking about, suddenly the whiteboard we have today, can become so much more. What happens when a Visio diagram becomes 3D (because at some point it will be a Universal App right?) and now we can interact with each the elements as holographic objects.

Take the last example and lets take it into a Holodeck style room. Now a real estate company can visualize a map of an area and have all the participants again represented by avatars. But now they can collaborate on which areas to focus and maybe even overlay what their new development could look like. Maybe instead they take a walk through of a new building that an architect rendered for them even before it is built.

Conclusion

In my mind, Microsoft has quite a bit of work to do to enable this type of collaboration. We need a new type of media and SDP application type. Skype clients have to be written for the HoloLens that not only can talk to Consumer Skype, but also Skype for Business. That client also needs to be aware of the PC client as well, because along with HoloLens type data, there will no doubt be the need to share Desktops, PPTs, and other more traditional content.  There will be privacy issues that will need to be addressed, because now with a device like this, it will be hard for people to know when they are on camera or not... or even more important when they are being recorded.

Finally I think it would be stupid to not assume that every Unified Communications manufacturer is now starting to brain storm what HoloLens means for them. This is after all a device based on Windows 10 and has an API that they can leverage the same as Microsoft can. Obviously Microsoft has an advantage when developing for their own platform, but none of what I've written here is strictly something that only Microsoft can accomplish.

I'm excited for what the future holds with this new Holographic computing.

Tuesday, January 20, 2015

Gotcha with AudioCodes 2013 SBA Patching

So I happened upon on interesting tidbit of information while patching an AudioCodes SBA today. Unfortunately I was trying to fix a customer issue so I didn't take the time to do screen shots... I'll try to update in the future with a set of screen shots, but hopefully the words will be enough for now.

It used to be on Lync 2010 SBA with AudioCodes they wanted you to patch only by the web interface, I never understood why we couldn't just run the LyncServerUpdateInstaller.exe on the desktop and be done, but like a good installer I know when to push limits and patching ain't one of them. In order to do this you had to extract out 4 patches, which matched up to the components listed in the screenshot below. The screenshot is from a 2013 system, but the 2010 system looks similar. 



Fast forward to 2013 SBA and I dutifully patched all the components listed. However, I happened to run the LyncServerUpdateInstaller.exe just to check and low and behold the Windows Fabric component still needed to be updated. With a big sigh... I got that .msp file and uploaded via the web interface and it said the update completed successfully... Sweet!

Wait... lets check the LyncServerUpdateInstaller.exe file again... nope not updated. "Oh wait" I said to myself in my head... I think it needs a reboot. One reboot later... still not updated.

I finally ran the LyncServerUpdateInstaller.exe and kicked off the update from there... which did require a reboot and low and behold it is now updated.

So with this new found knowledge I decided to go pull down the latest AudioCodes 2013 SBA Update Product Notice from AudioCodes related to updates and guess what? RDP patching is now one of the methods specifically called out. Also of note in that PDF, when you are patching via the web method there is zero mention of the Fabric Update. 

I also did check the latest AudioCodes 2010 SBA Update Product Notice and it allows RDP update too...

But here is the morale of the story for Lync 2013 SBA, patch only via RDP interface for AudioCodes to get all the updates on the box.

You may or may not be able to apply this knowledge to Sonus. Feel free to give feedback if you have experience in that area.

Tuesday, January 13, 2015

AudioCodes Configuration Logic

I've been working with AudioCodes products since the early 2000s. My first encounter was a couple of Mediant 2000s with 16 PRIs each. The configuration of those boxes for the most part was handled by following a document provided by Nortel. The funny thing is that most of the documentation over the years that has really helped has been solution specific guides done by a product manufacturer so that Audiocodes can work with their product.

The problem with Audiocodes is that its capabilities are so diverse and flexible that writing a single document that actually helps you through your specific configuration is nearly impossible. Years ago, you could actually download ready made configurations depending on what your PRI connection it was and you would be 99% there. Fast forward to today and configurations aren't that simple anymore.

The number one complaint I hear about Audiocodes is that it is so hard to configure and other products are ready to go in minutes. While I can't create any fancy wizards for Audiocodes configs, I can try to help people understand key parts of the AudioCodes configuration process so that the product is not as frustrating.

Global vs Profiles

One of the big concepts to get with Audiocodes is that there are many parameters that can be set at a Global Level and then overridden by a profile that applies to that feature. Profiles are useful for changing the behavior of communications to a particular system. For instance, if one system supports Early Media, but another does not, with Profiles you can adjust the signalling for each system. This applies not only to the IP side of the gateway, but  also the TDM side if applicable.

Another key concept with profiles is where you can have them applied. Some profiles, like IP Profile can be chosen in several different areas, which I think adds to the confusion on configuration sometimes. For example if I am using an IP Group, I can specify not only a Proxy Set, but also an associated IP Profile. If I'm not using IP Group but instead specifying a single target IP in the routing area, again I can specify an IP Profile on the route itself.

As a best practice, I always use profiles to control the various different features for each system, even if they need similar settings, they each get their own profiles so I can adjust individual settings in the future.

Before I go any further I need to mention a couple of basics. First of all, when looking at the menu's I always recommend changing to the the Advanced or Full view depending on the system you are looking at.



Also, whenever you hit "Submit" the change takes effect immediately unless the system tells you it needs a reset. However, if the system has a power loss and you have not hit "Burn" then the changes are not saved permanently to the configuration. It is a good habit to burn frequently. It only takes once of having to redo your configuration to learn the lesson.


I also highly recommend doing backups of the configuration. Which can be done manually or you can use my PowerShell script to do the backup



IP Groups

IP Groups are awesome because they pull together several different key pieces to communicating with other SIP systems. I use IP Groups primarily because I can specify a Proxy Set which allows for me to specify multiple IP addresses or DNS names for the system to send SIP signalling to, but I can also specify an IP Profile to be used too. This is key if you have multiple servers you need to communicate with that act as a pool or cluster.


Below you can see where we specify a proxy set (identified by a number) and the IP Profile as well. One thing to keep in mind is that you have to specify a SIP Group Name which ends up being the portion after the "@" in a SIP URI. The AudioCodes gateway/SBC doesn't really care what you put in here, but the far end system might. In the example I used the IP address configured on the AudioCodes network interface that communicates with that system. The network interface used is controlled by the SRD and Media Realm specified. If you have a system that uses a single IP, SRD and Media Realms is not used.


In the example below this is an SBC Enabled Mediant, so the SBC settings are exposed in the IP Group. Below are the defaults, which are fine most of the time, but if you needed to do some message manipulations for this IP Group this is where it would be specified.




IP Profiles

 As mentioned before, IP Profiles control much of the SIP signalling and allow for adjustment per system we are communicating with.


I think many of the parameters are self explanatory, and if not the documentation can help understand what each of these parameters do. Most of the really good stuff in the example I've provided is in the SBC section below. If you have a TDM based gateway there options are different but many are similar.


The SBC area of the IP Profile is really one of the key aspects of SIP Signalling and truly is what makes an SBC a Back to Back User Agent and allows for the adjustment of signalling between disparate systems. As an example, one of the latest items I've had to adjust was the hold format to Intelepeer SIP Trunk that did not like the hold format Lync used. 

Because this was an SBC Application enabled configuration, I could accept the hold format from Lync and send a different hold format to Intelepeer. Another piece that can be useful is controlling the REFER behavior, which sometimes has to be set to Handle Locally to keep disparate systems happy that don't understand REFER.


Coder Group

Coder Groups are pretty basic allowing you to specify a codec list and features (such as silence suppression) to be used when specified in an IP Profile above. If you have ever heard of transcoding between different codecs, this is where that magic happens for AudioCodes. You can specify G.711 for one IP Group and IP Profile and then specify G.729 in a different IP Group and IP Profile combination.


Tel Profile

This is taken from a TDM based system and not the same as the examples above from an SBC. I wanted to talk a bit about Tel Profiles because I've found having a different one for each one of your TDM lines is crucial. Tel Profile for each TDM trunk is specified in the Hunt Group area when you define what your different ports are doing.

Why?

Couple of features... Echo and Analog DID.

Controlling the volume is key for solving echo issues. Other than misconfigured microphones, the number one cause of echo issues is volume being too loud. Being able to control volume from PSTN (Input Gain) and to the PSTN (Voice Volume) for those lines that are too loud is the key feature that helps address the issue. Why is this? Because when the volume is too loud the reflected audio back from the far end isn't detected by the echo canceler and allowed to pass through as normal audio. If you wanted to see this for yourself, increase the volume to the PSTN to the point where it causes echo.

Also, if you have the unfortunate luck to encounter a site with Analog DID then Polarity Reversal and Enable DID Wink are key features in the Tel Profile you will need to enable on a per port basis.



VoIP Routing

One of the more confusing aspects of the AudioCodes configuration is VoIP routing (non SBC Application). The key is to make note of where the communications is coming from. This determines which of two routing tables you will hit. If the call is starting from the TDM/PSTN world, then you will hit the Tel to IP routing table. If you are starting from another SIP system or SIP Trunk then you will hit the IP to Tel routing table.

Sometimes, it is necessary to route from PSTN to an Analog port and in order to accomplish this you have to route the call to the gateway itself. The first line below is an example of that. Once you do this you will now hit the IP to Tel routing table which allows to routing to a Hunt Group (which in turn was assigned an Analog port).

Conversely, if you start in from another SIP system and you need to route to another SIP system through the Audiocodes, the call would hit the IP to Tel routing table first. The key to routing to the Tel to IP routing table going this direction is sending it to Hunt Group "-1". This technique may be necessary if you need to route analogs from MediaPack to MediaPack and want to keep it entirely in the AudioCodes world.



One other thing that almost always comes up is manipulation of numbers either Destination (Called) or Source (Calling). In the screenshots above the setting is to Route before Manipulation. This is my preferred method, but it is important before you start manipulating to understand if the manipulation will occur before or after routing. This will determine which numbers you put in your routing tables.

Now that I've mentioned this, I try very very hard not to do any manipulations in the gateway/SBC. I prefer to do all this in Lync. Sometimes there is no way around it, especially if you need to deal with manipulations when doing Fax or other analog solutions.



Dialing Plan Notations for Prefixes and Suffixes 

AudioCodes is not nearly as flexible as RegEx when it comes to number matching, but it isn't terrible if you know what you are doing. Below is from the AudioCodes documentation.

The dialing plan notation applies to the Number Manipulation tables, 'Tel to IP Routing' table and 'IP to Trunk Group Routing'. The dialing notation applies to digits entered for the destination and source prefixes to represent multiple numbers.

[n-m] Represents a range of numbers. Note: Range of letters is not supported. 
Example [5551200-5551300]#: represents all numbers from 5551200 to 5551300. ��123[100-200]#: represents all numbers from 123100 to 123200.

[n,m,...] Represents multiple numbers. Up to three digits can be used to denote each number.
[2,3,4,5,6]#: represents a one-digit number that starts with 2, 3, 4, 5, or 6. �� [11,22,33]xxx#: represents a five-digit number that starts 11, 22, or 33.
[111,222]xxx#: represents a six-digit number that starts 111 or 222.

x Represents any single digit. 54324: represents any number that starts with 54324.

Pound sign (#) at the end of a number Represents the end of a number. 54324xx#: represents a 7-digit number that starts with 54324.

A single asterisk (*) Represents any number. *: represents any number (i.e., all numbers).

Conclusion

Give me some feedback on whether this hit the mark or not. I have a lot of information about AudioCodes up in my head and like the people that write the documentation, it is difficult to get it into a usable format for a wide audience.

Tuesday, September 30, 2014

Failed Lync Server 2013 Prerequisites on Server 2012/2012 R2

This issue has caused me grief on several servers this week and I finally figured it out... so now you benefit.

If you wait to install your Prerequisites after you run Windows Update on Server 2012/2012 R2 you will get an error


I really doesn't matter what you specify as you "Source" the Prerequisites Powershell command we all love will fail.

So if you do searches you will come across others having this issue. They solved it by running.

     dism /online /enable-feature /featurename:NetFX3 /all /Source:d:\sources\sxs /LimitAccess

Which would help... but there is one last key piece of information I'll give you... which is the point of this blog because I found the answer in a comment on an obscure blog post.

If KB2966827 or its brother KB2966828 are installed the dism command will fail to install about 67% of the way in.

Not surprisingly the work around is to uninstall either of those two KBs... or to do your Prerequisites before you run Windows Update.

There you go... my pain is your gain. Enjoy.

Thursday, August 21, 2014

So... you want to be a Lync Architect

For at least a couple years now my employer has been on a constant search for talent to deploy Microsoft Lync and the components that are part of that ecosystem. But it is getting harder to find guys that will fit in with the company culture and have a good set of fundamental skills (or phenomenal skills if we get lucky).

So I thought I'd write a post, from my perspective, about what some of the skills are that it takes to work as a consultant in this Microsoft Unified Communications world. Engineers and Architects that can do this type of work WELL are a rare find. They posses knowledge from multiple disciplines (data, voice, server apps, security etc) and combine them all to help a customer deploy a solution that fits their needs. My hope is that this will finally convince some people that are on the fence to jump in (and increase the pool of talent).

... and no you don't have to be an Architect to jump in, you can start out being an Engineer or working the support desk. You can learn as you go.


The Hard Skills

Here is the bottom line... the more of these the better.

The more of these you are excellent at... the better consultant or support engineer you'll be for your customer.

Nobody... Nobody will be an expert at all of these. But sometimes the secret is knowing others that are experts in that area... or knowing where/how to find the answers.

If you are weak in most these areas... no problem... go buy a computer, create a lab of your own and pick something and start to learn. With Microsoft based software there is usually no lack of freely available knowledge you can learn from and there are certainly plenty of books out there on all of these topics. Don't expect you will learn all of this in two weeks. I've been gathering knowledge for as far back as 20+ years and that knowledge still applies to what I do today. But everyone has to start somewhere.

Here is the list that I've come up with...
  • Active Directory
  • SQL Server
  • Windows XP/Vista/7/8/8.1 etc
  • Server 2008 R1/R2 and 2012 R1/R2
  • Office Communications Server 2007 R1/R2
  • Lync Server 2010/2013
  • Exchange 2007/2010/2013
  • System Center 2007/2012/2012 R2 via @fabriziovlp
  • Hyper Visors (Microsoft, VMWare etc) via @fabriziovlp
  • Virtual Desktop Infrastructure (Microsoft, VMWare, Citrix etc)
  • PowerShell
  • .Net Regular Expressions (RegEx)
  • Private Key Infrastructure/Certificates
  • Layer 2 Networking (Switched)
  • Layer 3 Networking (Routed)
  • IPv4
  • IPv6
  • TCP/IP
  • Quality of Service
  • Firewalls
  • Network Sniffer (Wireshark, Message Analyzer)
  • SIP
  • Audio Codecs (G.711 etc)
  • HTTP/HTTPS
  • ISDN PRI and the associated protocols/capabilities
  • T-1 (Telephony based digital circuit)
  • DS-1/DS-3 (Data based digital circuit)
  • Frame Relay
  • Avaya Blue (Nortel)
  • Avaya Red (Traditional Avaya)
  • Cisco Unified Call Manager
  • Mitel
  • Inter-tel (owned by Mitel now)
  • Shoretel
  • PBX Dial Plans
  • PBX Features
  • Analog device types
  • Fax and Fax Server
  • T.38 Codec (for Fax over IP)
  • Modem (Yes credit card and postage machines still use this)
  • Gateway/SBC (Sonus, Audiocodes, etc)


The Soft Skills
  • Good listening skills
  • Good presentation skills
  • Good communications skills (verbal and written)
  • Patience
  • Attitude toward constant learning
  • Self starter
  • Working alone
  • Working in teams
  • Working with other teams
  • Juggling lots of tasks/jobs at once
  • Prioritizing tasks
  • Bing/Google searching for information
  • Networking (the people kind)

Getting There...

This one is all on you. My unique path took me from being a network manager/admin at a University, to working 11 years for Nortel and then combining all that experience into what I do now. Some of this is hard to learn in a lab unless you are loaded with money. 

You need to surround yourself with people that know about the skills you need to work on. This is where the networking (the people kind) really comes in handy.

How do you do this?

  • Go to local users groups
  • Go to local conferences. 
  • Go to some industry conferences. 
  • Get on twitter and follow people that tweet about the things you want to learn about. 
  • Get on LinkedIn and make some connections and join some discussion groups. 
  • Read the Technet forums
  • Read some books
I'll keep updating this as I think of things... but bottom line is that this stuff isn't easy, but it is something that is able to be learned given enough time and effort.

Monday, June 9, 2014

Lync Centralized Logging Service AlwaysOn filling up hard drive

Issue

Customer was running the AlwaysOn scenario with Centralized Logging Service on Lync Server 2013. The drive was filling up with .etl files when we had set the "CacheFileLocalMaxDiskUsage".


When I observed how this was operating on a working system, I noticed as soon as the .etl file rolled over to a new one (at 20MB), it would be converted to a .cache and .hdr file and the .etl file would be deleted.

So clearly the issue was the .etl files not being converted and then deleted. This allowed a huge amount of disk space to be chewed up and for disk alerts to be sent by the customers monitoring application.

Note: if you are trying to track down where the .etl files... it does no good to type %temp%/Tracing in the run command. That will go to the currently logged in user temp directory /tracing. The Centralized Logging Service runs under "NetworkServer" and can be found:
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing

Resolution

This will be an obvious one, but it still may catch people, so that is why I'm putting this blog together. The culprit was Symantec Antivirus. Once this was disabled the .etl files were converted to .cache and .hdr files as expected. The centralized logging service should have been excluded per the Technet article about excluding executables and directories for Lync Server 2013 (http://technet.microsoft.com/en-us/library/dn440138.aspx).

AT&T Hosted Firewall preventing Desktop/Application Sharing through Lync Edge

Issue

Ran into this problem a while ago and just now getting around to writing about it... but it is one of those head scratch kind of problems, until you compare a working system with the non-working system. In this case, I spotted the problem of Desktop/Application Sharing across the Lync Edge server in Wireshark when the client went to STUN the server on port 443.

I didn't realize this, but there actually is a momentary TLS negotiation on 443 STUN and the failure from the AT&T Hosted Firewall looked like this.



From the Lync Edge server perspective everything was successful. But the AT&T Hosted Firewall in the middle of the TLS negotiation was sending back this "Level: Fatal, Description: Access Denied" error instead of what the Lync Edge Server responded with. This was both an issue for Lync Server 2010 and 2013.

Resolution

The jist of the resolution was to request AT&T to do a Policy Bypass for the IP Addresses associated with the Lync Edge server. The problem was with STUN, but I would probably ask they bypass any other IPs if you have multiple IP addresses on your Lync Edge servers.

Just in case that doesn't get you far enough... I have below verbatim what was send back... so that you can coax the Level 1 support technician to find someone that really knows what they are doing (my cust went through several support people before he found someone that could fix this).
“What I did to correct the issue is to remove the Protocol Option filter from rule 4 and rule 17 in the policy that was being used for the Lync traffic.  Protocol options tell the firewall to check further into known traffic types such as http, https, smtp, ftp, etc. for expected settings.  On the HTTPS side one of those checks is ‘Allow invalid SSL certificates’ which is not enabled by default.  Since the filter is used by most of your rules in your policy I didn’t want to enable this and have all of those rules using it so instead I removed the filter from these two rules.  If you would like it re-applied but with the setting enabled a separate filter can be configured with that setting enabled and just apply that filter to the two rules.”