Friday, November 23, 2012

Lync Server 2013 HA Design Changes and Considerations

Lync Server 2013 introduces new capabilities for recovering from a single server or pool failure and failing over between pools of servers; either Enterprise or Standard Edition.

This post discusses these capabilities, demonstrates their use, and offers suggestions for organizations wondering which path to choose.

Lync Server 2013...what's changed?
  1. Enterprise Edition pools now are recommended to have a minimum of three, yes THREE front-end servers. This is due to the "Windows Fabric" replication architecture based on Azure. The back-end SQL database is no longer the store for real-time data.
  2. (subject to change) Enterprise Edition pools use a quorum model similar to Exchange Server 2010/2013 in that a Majority Node Set (MNS) quorum leverages a tie-breaker for pools with even-numbered front-end servers. In the case of Lync Server 2013 this is the pool back-end SQL server.
  3. Enterprise Edition pools no longer support SQL Server clustering for HA.
  4. SQL Server mirroring is now the supported method of providing back-end database resiliency.
  5. For automatic failover of a SQL mirror, a SQL witness is required; this can be SQL Express. Collocation of other services, software, etc. are subject to further testing.
  6. Lync Server 2013 uses a Web Application Companion (WAC) server (aka Office Web Apps) to stream PowerPoint meeting content including full transition support and embedded videos.
  7. Lync servers can be "paired" with like-infrastructure (Enterprise to Enterprise and Standard to Standard) to ensure resiliency in the event of a site outage (DR). This pairing activity ensures replication of critical pool/server data and must be invoked by an administrator via manual PowerShell commands.
  8. Multiple Federation routes can be applied to the topology. For example, a Boston Standard Edition server can use a Boston Lync Edge server as its Federation route whereas a Seattle Enterprise pool can use a regional Seattle Lync Edge server/pool for Federation.
Now that Enterprise Edition pools can be paired with other EE pools, and Standard Edition servers can be paired with Standard Edition servers, this changes how we design Lync solutions in certain cases. I talk to customers who often suggest they need "High Availability" (HA) in their Lync infrastructure and this often comes from those who are implementing IM&P only. Instead of trying to meet some kind of unrealistic expectation or design to a requirement which centers around a term like HA, drive the conversation toward Recovery Time Objective (RTO) and Recovery Point Objective (RPO). These two factors, along with an Service Level Agreement (SLA) percentage (i.e. 99.9%) should drive the outcome. Anyway, here is the rule of thumb I use personally today:

If the organization suggests they need HA are they willing to accept a Recovery Time Objective of >1 hour? If so, and the per-server user count does not exceed ~5000, use Lync Standard Edition. Two Lync Standard Edition servers could even be used to split the load of 5000 users in a location where 2500 are homed on each server and both servers are paired (backup for each other). The build list would look something like this:

2 x Lync Server 2013 Standard Edition servers (paired with each other in the same site or stretched between a primary and DR site)
2 x Lync Server 2013 Edge servers
2 x Office Web App servers (WAC)

If the organization insists they cannot incur downtime for Lync components contained within a single site, and they insist "high availability" is a requirement, the infrastructure looks something like this:

3 x Lync Server 2013 Enterprise Edition servers
2 x Lync Server 2013 Edge servers
2 x Office Web App servers (WAC)
2 x SQL Standard or Enterprise Servers
1 x SQL Express, Standard, or Enterprise (witness)
2 x File servers using DFS
2 x Hardware Load Balancers (for the EE pool and WAC servers)

But wait....I need DR!
If the organization also insists they have a plan for Disaster Recovery, a second "warm" site would house the following minimum infrastructure:

3 x Lync Server 2013 Enterprise Edition servers
2 x Lync Server 2013 Edge servers
2 x Office Web App servers (WAC)
2 x SQL Standard or Enterprise Servers
1 x SQL Express, Standard, or Enterprise (witness)
2 x File servers using DFS
2 x Hardware Load Balancers (for the EE pool and WAC servers)

That's 24 servers to build a site redundant Lync Server 2013 Enterprise environment. This may seem a bit ridiculous however the point I'm illustrating is the value Standard Edition now brings in Lync Server 2013. Additionally, I haven't found an organization yet who would dedicate server hardware or VM's in this manner. You can collocate many of the roles and scale back on things like WAC and SQL mirroring. Lastly, organizations might suggest their DR infrastructure would accommodate lower user counts which may drive a design lacking redundancy at the "warm" site.

Hold on....what about Persistent Chat?
Okay, so you want a Persistent Chat pool as well....we need to add dual redundant servers at each site raising the total to 28 servers.

As you can see the case for paired Standard Edition servers quickly becomes favorable from a cost and complexity perspective albeit sacrificing availability in the event of a single server outage. The fact that hardware load balancers can be completely eliminated also tells a great story around simplicity. To date I have yet to see a successful implementation of OCS or Lync where hardware load balancers are in the mix at all. This is mostly due to lack of knowledge, lack of understanding on how the solution works, or in some cases simple reluctance to work together.

What if I have more than 5000 users at a single site and need DR?
Consider placing multiple Standard Edition servers paired with similar servers at your backup sites. You can split users homed between servers (i.e. 3000 on ServerA in SiteA and 3000 on ServerB in SiteA) to meet your capacity requirements.

What are the drawbacks to Lync Standard Edition anyway?
Well the first point people typically jump on is no "high availability". This is obviously due to the lack of a shared common data store whereby multiple front-ends connect and relate to. Here are some of the more important drawbacks when considering this approach:
  1. Restoration of service is a manual effort resulting in users being left with "Resiliency Mode" until this action is taken.
  2. Your Edge proxy to 'next hop' internal server can be only one SE server even if you have several of them. An outage to this next hop server results in an outage for all remote users' traffic. It is important to note as well that if Edge cannot contact the next hop, clients will not attempt to sign into another Edge proxy even if another exists (without manual intervention at each client system).
  3. Response Groups and Call Park are a manual effort to switch over.
  4. Assignment of users to a collection of SE servers takes thought and proper assignment so as to not overload a single server. In the case where you have two servers, decide if you're going to run them active/active or active/passive as this will change your user placement behavior. This can also be scripted for ease of user placement automatically.
  5. You could argue this is more complex to manage however the same argument is made for the HLB/SQL infrastructure required.
  6. Your PSTN conference DID is homed to a single server. If this server is down, the DID is as well. I have not yet tested the behavior of a pool failover whether this DID is restored on the backup registrar or not (TBD).
  7. Exchange OWA/UCS integration has a single point of failure due to the lack of multiple server definitions in the Exchange 2010/2013 CAS setup.
Certainly you will have to weigh your own requirements against what is both supported and recommended. This article is intended to keep us thinking on our toes when designing Lync solutions for our customers. Enjoy!

Tuesday, September 4, 2012

Easy way to meet pre-requisites for Lync Server 2013 on Windows Server 2012

I build VM's with Lync Server 2013 every few days now testing failover and rebuild scenarios so I have everything worked out in my thick skull...

Until recently I used to memorize the requirements of the OS including IIS sub-feature components and often missed one item along the way. Since working with Windows Server 2012 I've found an easier way to meet the pre-requisites for Lync Server 2013 which I'm sure you'll find just as easy.

The process involves modifying a configuration XML file, and running a PowerShell command.

Step 1: Download (and rename) the XML file from my SkyDrive site
This file contains the Windows Server 2012 roles and features required to set up Lync Server 2013's basic feature-set.

https://skydrive.live.com/redir?resid=D6DA5D3A463728DA!947&authkey=!AJQgC9sDTF_36Ow (updated on September 4, 2012 @ 3:11PM)

Step 2: Modify the XML file
Open the XML file in Notepad and perform a find/replace on the "lync2013-02" name and type the name of your local server. Save the file to a location on your server making note of the path and file name.


Step 3: Open PowerShell as an Administrator
Right-click the PowerShell icon on the taskbar and choose "Run as Administrator"



Step 4: Run the PowerShell command
Next, type: "Install-WindowsFeature -ConfigurationFilePath C:\lync2013\lync2013pre-req.xml -Restart"


Once the roles and features have been installed, the server will reboot and will be ready for Lync Server 2013.

 NOTE: My lab environment required access to the Internet for the setup to complete otherwise it failed with an error indicating it couldn't connect to the source files. Not sure of this was an anomaly or what...



Tuesday, August 28, 2012

Lync Server 2010/2013 and Cisco/Nortel/Avaya integration

UPDATED: Slight change in my approach here. As it turnes out we only need to drop the plus sign on sim-ring users. Read on...

I suppose the article name is somewhat misleading as the following information is really pertinent to just about any Lync Server 2010/2013 implementation involving a PBX. New Lync Server 2013 features notwithstanding, I'll provide a few scenarios for implementing the more common (Cisco/Nortel/Avaya) PBX systems on the market today and demonstrate what I believe is the perfect compromise between world domination and exile.

I'm engaged with customers on a regular basis who have an existing legacy PBX (i.e. Nortel/MITEL) or have completed a new implementation (i.e. Cisco/Avaya) of an IP telephony solution. As an afterthought they have visions of a perfectly integrated Unified Communications strategy involving multiple vendors including Microsoft's Lync Server platform. Some of the common questions I hear are:
  1. We've just completed our Cisco Call Manager installation, have deployed IP phones, and we simply don't like their desktop software story. We want Lync on the desktop but don't want to lose our investment in IP telephony. Can you make them work 'together'?
  2. We like what Lync has to offer but we simply can't remove our PBX yet due to call center integration and feature limitations. We want users to keep their identity and voicemail platform on the PBX. How can you integrate Lync with our existing systems?
As an advocate for the Microsoft UC platform, I used to consider anything short of a full Lync IP telephony deployment a failure. After realizing we can't win them all...I've softened up a bit and since then have come up with a solution I believe is a great balance between ripping out the PBX and losing a Lync deal.

Before we get started you need to forget one of the most important rules you've learned; you won't be using E.164 format for the LineURI in Lync. Actually we will, sort of. The purpose of using E.164 as a numbering standard is because your dial plan is exposed across the AD forest. In other words the LineURI needs to be globally unique enough to prevent collision with another number.

So let's start with common customer requirements. In some cases customers will want voicemail to remain on the PBX and are strictly against Exchange UM for compliance or political reasons. In other cases customers want voicemail both tied to the IP phone and the Lync user. I'll outline options for both scenarios.

Customer requirements:
  1. We need Lync users enabled for Enterprise Voice (EV).
  2. EV-enabled Lync users must keep their IP phones.
  3. IP phones should have voicemail homed on the PBX.
  4. Calls to IP phones must also ring the Lync user (sim-ring).
  5. Caller ID for calls from Lync to PBX or PSTN should represent the PBX DID. Additionally, users authenticating to a Lync PSTN conference need to authenticate with their real DID and PIN.
  6. Lync to Lync calls via click to call (contact card DID) or simply keying in the user's DID must ALWAYS leave Lync and ring the PBX first.
To many who design Lync environments this can be a difficult list to adhere to. In many cases the most difficult requirement is the last one because of "Reverse Number Lookup" (RNL) in Lync Server. For those who don't know what RNL does, it is a process by which Lync Server will perform a lookup of the dialed number (the "A-party") and if a match is found it will ring the user's SIP URI. Any other IP-PBX system does the same thing however in Lync we call it RNL. In cases where a person performs a click-to-call (i.e. contact card in Lync or number on a web page), RNL will find the SIP URI of the called party and the call will never leave Lync and ring the IP-PBX phone. So how can we force Lync to send calls to the PSTN in the click-to-call scenarios?

Let's focus on requirements #4, #5, and #6 as they are most relevant here.

Scenario: Alice is using her IP phone (7805551234) to call Bob's IP-PBX phone (7805553001) where the call is forked to Bob's Lync identity (SIPURI: bob@contoso.com and LineURI: +17805553001;ext=3001). Let's look at the requirements again:

4. Calls to IP phones must also ring the Lync user (sim-ring).
The PBX really needs to own this feature however we need to ensure we work with the telecom teams to design a solution which will work with Lync. In the case of Cisco, the Mobility feature must be used to sim-ring the Lync number and in cases where Nortel is used, PCA licenses may be required for the same purpose/feature-set.

Similar to the RNL feature in Lync, other PBX systems need a unique number represented by the sing-ring so as to not cause a loop or sim-ring call to end up directed at voicemail instead of Lync Server. For this purpose I'd recommend using a steering code (prefix called party with a series of digits). For example, if Alice (7805551234) calls Bob (7805553001) we need the PBX to fork the call to a third number for Bob (89+7805553001). The PBX adds the "89" steering code which is used in their routing engine to send the call to Lync via Direct SIP or a Gateway.

To simplify the configuration we need Lync to strip the steering code so the number can match Bob's LineURI attribute in Lync.

NOTE: Common mistakes are to set Bob's LineURI to "897805553001" which breaks requirement #5 or to use a phantom non-DID such as "3001" which also breaks #5 and #6.

Don't use the gateway to this work as it only complicates the solution. Within Lync Server create a pool-based dial plan tied to your IP gateway object and within it create a normalization rule to strip the steering code. For example "^89(\d{10})$" translates to "$1". This means Lync will attempt to perform RNL against 7805553001 specifically.

NOTE: Another common mistake I've seen is Lync administrators writing inbound normalization rules to handle the 'non-DID' formatted number (with the ;ext= attribute). You don't need to worry about this as a call to 7805553001 will match both 7805553001 and 7805553001;ext=3001. Beware however that if you have a base number of 7805553001 assigned to a Lync user along with extensions off the same base number such as 7805553001;ext=1301 and 7805553001;ext=1302, etc. This will result in a failed call as it is too ambiguous (SIP/2.0 485 Ambiguous).

So now that Lync receives a call for 7805553001 and matches Bob's LineURI which is 7805553001;ext=3001 we have met this requirement. Both Bob's IP phone and Lync will ring. The only real change to a typical dial plan is that we've removed the country code (North America=1). Again going back to my E.164 discussion above, by removing the "1" we've potentially made the number less unique however I would submit to you that in 100% of the cases I've seen this isn't an issue because we're using the ";ext=" attribute to gain uniqueness again. In other words if you have a collision in your dial plan as a result of "7805553001;ext=3001" not being unique enough come talk to me!!

5. Caller ID for calls from Lync to PBX or PSTN should represent the PBX DID. Additionally, users authenticating to a Lync PSTN conference need to authenticate with their real DID and PIN.

Since we've given Bob a LineURI of +7805553001;ext=3001 his caller ID to the PBX from Lync will be displayed correctly. In Lync Server 2013 you can optionally build trunk de-normalization rules to strip the ;ext=3001 from the caller ID if necessary.

Bob's LineURI also permits him to authenticate to Lync PSTN conferences using his PIN and even his 10-digit number if necessary. Never give Bob a 'fake' LineURI as this only adds confusion in the Dial-In conferencing page and with his experience in authenticating to the bridge.

6. Lync to Lync calls via click to call (contact card DID) or simply keying in the user's DID must ALWAYS leave Lync and ring the PBX first.

So this is often the most tricky to achieve not only because of RNL but also because of "Global Numbers". What are Global Numbers you ask? Lync will never use client-side or server-side normalization rules for numbers prefixed with a "+" sign. This is very important in click to call scenarios as you would possibly expect +17805556009 follow client-side normalization. It will not as it assumes the number has been pre-formatted already on purpose.

So the challenge is....when a Lync user selects a user's desk phone number from their contact card, how can we bypass RNL so the call leaves Lync and rings the PBX? Well the secret again is in the LineURI format.

NOTE: I've seen people hack away at the Address Book normalization rules to present a different number format in the contact card; don't do this! Remember....contact card is also visible to federated users as well and if you're representing a number only relevant to you, this will break their click to call scenario. Leave your address book normalization rules as they should be and normalize to E.164 format ALWAYS. Secondly, if you've enabled Call Admission Control and a situation occurs where your call is blocked due to a CAC policy, we need the LineURI number for PSTN reroute.

When Bob clicks on Alice's contact card to call her DID on the PBX it shows up as +17805551234. Since Alice is also a Lync user with Enterprise Voice, her LineURI is +7805551234;ext=1234. This will result in a failed match by RNL and Lync Server will then route the call to the PBX. Optionally you can use trunk de-normalization rules to strip the "+1" from the called party ID.

A word about voicemail...
In many of these cases customers are interested in trying out the features of Exchange UM to the point where we install a server as a pilot initiative. The issues we face with integrating Lync and Exchange with another PBX or IP telephony solution often circle back to Lync's limited integration with 3rd party voicemail platforms. Said another way, you cannot connect Lync to any other voicemail platform than Exchange UM. This certainly isn't a dig against Lync as the amount of engineering gone into the 'better together' story of Lync and Exchange is simply staggering. I understand the investment and need to protect that. So the real question is....what's the best way to make this all work?

Let's start with what your options are, describe the pros and cons of each, and I'll provide my recommendation.

Option 1: Keep voicemail with the PBX
In this scenario the IP phone will remain paired to the voicemail platform in place today and the Lync EV user isn't UM-enabled. Since we're sim-ringing into Lync, a call gone unanswered will divert to the PBX voicemail platform. In an environment politically charged with fear of job loss due to VoIP in general, the upside is people feeling more comfortable about the solution and overall simplicity. The theme is "Lync is simply a 'bolt-on' and I'm not going to lose my job because of it". The downside is Lync to Lync calls will end after 20 seconds.

NOTE: Keep in mind you will want to introduce a GPO for Lync to turn off the feature to "Save call logs in my email Conversation History folder" as this will result in a missed call notification for every call answered by the PBX on a sim-ring into Lync.

Option 2: Keep voicemail with the PBX and enable the Lync user for UM.
Enabling the Lync user for UM will resolve the downside issue in the previous example so we consider this to be a pro. However there is an argument to be made about complexity as call routing scenarios could result in missed calls going to one of two voicemail platforms adding confusion to the user experience. Add to this the ability for a Lync user to sim-ring, call forward, or team-call a series of other Lync users and the call routing/destination could be any one of hundreds of possibilities.

Consider the following: Bob, a PBX user with voicemail is set up to sim-ring his Lync account which is also UM-enabled. Bob set up sim-ring in Lync to ring his cell phone at the same time. While out of range, or with a dead battery, Alice calls Bob. What happens to the call? The answer is....Bob's cell phone voicemail will. Confusing? Maybe not for someone who understands the solution but to Bob it most certainly could be. You could resolve this by disabling call forward and sim-ring via Voice Policy in Lync however at this point the added complexity to neuter Lync seems like a lost cause.

Additionally, this method is a little more tricky as you not only need to take the above GPO setting into account, you also need to turn off missed call notifications in the UM dial plan.

Option 3: Move voicemail from PBX to UM and enable the Lync user for UM.
This one seems to have the most promise but comes with a significant "con". The biggest advantage here is that users have a consolidated voicemail platform between the two systems which reduces confusion and complexity.

In this scenario we have an IP-PBX configured to use Exchange UM as the voicemail platform for Bob's IP phone. Bob is also a Lync EV user who we'd like to provide voicemail for sim-ring calls and/or Lync to Lync calls. The solution here involves the enablement of a secondary dial plan for Bob.

Here are a couple of things to consider:
  1. You must enable the Lync user for UM first.
  2. Then add the secondary dial plan which uses the IP-PBX as a UM IP Gateway.
  3. In this scenario the voicemail light (MWI) on the IP phone will not light up even with Exchange 2010.
At first glance the obvious "con" is the lack of a Message Waiting Indicator light on the IP phone could spell disaster. I have to say that it really depends on the organization you're dealing with. If you explain how Lync will show new voicemail in the system tray, in the client, and Exchange will show voicemail in the inbox, users typically have smartphones these days so they know immediately if they have voicemail even when they're away from their desk.....and on and on....sometimes its enough to convince them....sometimes it isn't.

Secondary Dial Plan Reference: http://technet.microsoft.com/en-us/library/ff629383.aspx

Recommendation: Option 3 some of the time...
Believe it or not I honestly can't say I've seen one solution work 'better' over another. It really comes down to customer requirements, their ability and willingness to test and take on new challenges, and maturity from an Exchange/Lync perspective.

Hope you all find this useful. I'll update and modify this article as I come across anything new or if someone reports an issue/error in the content.

Remember....Keep Calm and Chive On!

Thursday, August 16, 2012

Determine client versions with Lync Server 2010/2013

I've seen several posts on this subject including tools, scripts, and some really great information on how to retrieve client version information out of Lync. Formerly with OCS you used to be able to click the Database tab in the MMC and view client version summary in a nicely displayed table. With Lync Server 2010 this feature doesn't exist ---or does it?

Lync Server 2010 introduced the idea of user registration happening on the front-end servers (in an Enterprise Pool) instead of the pool database back-end. Standard Edition servers also record user registration in a 'front-end' instance of SQL called the "RTCLOCAL" instance. If you look at the Services MMC snap-in for an Enterprise Edition front-end server you'll notice a SQL Server service for the RTCLOCAL instance.

This instance is where user registrations are held, more specifically they are stored in the "rtcdyn" database within this instance.

To obtain client version data we can actually use the Snooper utility which ships with the Lync Server 2010 Resource Kit Tools. This tool can be found under C:\Program Files\Microsoft Lync Server 2010\ResKit\Tracing. Simply run this tool and select "Reports", then "Conferencing and Presence" from the menu.



In the "SQL Backend" text box type the name of one of your front-end servers if you're using Lync Server 2010 Enterprise Edition followed by "\rtclocal". If you're using Standard Edition, type the server name followed by "\rtclocal". For example:

Change the report type to "Diagnostic" and click the "Generate Report" button. Scroll down to the client version summary section to view the results.


To view client version information for other front-ends in the pool, simply change the server name and query them individually.

Good Refernce:

Doug's Blog on retrieving users and versions: http://blogs.technet.com/b/dodeitte/archive/2011/06/15/how-to-get-a-list-of-client-versions-and-the-users-logged-into-them.aspx

Wednesday, August 15, 2012

RESOLVED: Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Certificate Services policy

I was recently engaged at a client site where we used Lync Server 2010's UI for generating a private certificate for the customer's Edge server. The request was sent to their internal PKI environment and came back with the error:

Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Certificate Services policy.

The customer's Windows certificate server used a custom template based on the default WebServer template shipped with the OS. The template "friendly name" contained spaces such as "Contoso - Web Server v2" however the "short name" removes these and is referenced as "ContosoWebServerv2".

During the certificate request process in Lync Server 2010 you can specify an alternate template to use for signing the certificate. During this process I had specified the friendly name and not the short name which resulted in the error.

Once I changed the Lync Server 2010 certificate request template name in the wizard to the short name, the CA issued the certificate just fine!

Thanks to Dev for this one!

Thursday, May 17, 2012

RESOLVED: Lync iOS Mobile ERROR: Can't connect to Exchange Web Services. You can try again later.

Consider the following:

An organization uses two different DNS records for their Exchange Web Services URL:



The internal URL is not registered in public DNS. You sign into the Lync Mobile client from an iOS device. The client signs in but you receive an error shortly after indicating “Can’t connect to Exchange Web Services. You can try again later”.

Upon viewing the iOS logs we see the device receive only the Internal URL through the Exchange Autodiscover process. The External URL is never queried by the device and it’s unknown at this point if this parameter is given to the client or not.

What IS known is that the iOS client will only use the Internal URL parameter, in this case https://exchange.contoso.com/ews/exchange.asmx.

Additional Notes:

1.       A common misconception out there is that the iOS device cannot connect to UAG when it’s used to publish the Exchange Web Services, Autodiscover, or Outlook Anywhere URL’s. There is an issue where UAG is used to publish the Lync Mobility URL’s (lyncdiscover and external web farm fqdn).
2.       You MUST enable Outlook Anywhere on your Internet facing CAS servers for the Autodiscover URL’s to be given to clients (iOS/Lync 2010) on the Internet. However, you don’t have to publish the “/rpc/*” path through UAG/TMG.
a.       The same applies to the Lync 2010 client when it queries for conversation history or voicemail from Exchange when signed in remotely.
3.       You CAN use UAG to publish Exchange URL’s with TMG publishing the Lync URL’s.

Resolution:

1.     Publish your internal EWS FQDN in public DNS and make sure your TMG or UAG server has a certificate matching the public name you're using. If you have a wildcard certificate you're fine.
2.      Consider making the Internal and External Web Services URL's the same.

Thursday, March 29, 2012

RESOLVED: PING Transmit failed General failure

I recently assisted a customer in an engagement where a Lync Server 2010 Edge Server was being put into production. The server was pre-configured from an OS-perspective by another IT group and handed over to us for application configuration. Setting up Lync was straight forward however we noticed through the troubleshooting process that outbound communication on the External network interface was failing. Further investigation showed the server couldn't even ping it's own IP!

The error was: PING: Transmit failed. General failure.

After looking at the interface properties and TCP/IP v4 properties, we noticed NLB was enabled on the NIC. Unchecking this feature resolve the issue. We fought with this one for quite some time!

Hopefully this helps some of you out there.

Cheers....

Go Windows 8!!!

Tuesday, February 14, 2012

TOP 10: Exchange Server 2010 PowerShell Commands

Here you will find a collection of the most commonly used commands I run in Exchange 2010. Enjoy!

1. Check Database Availability Group Replication Status
In some cases you may have many copies of Exchange 2010 databases and you want to view the status of them all. This command will perform that task for you but also show you a very important characteristic such as the content index state.

Get-MailboxDatabaseCopyStatus

2. Fix a Failed Content Index
In rare cases you may notice the content index has failed. Activating a database copy with a failed content index requires additional guidance but to fix the problem beforehand, run the following.

Update-MailboxDatabaseCopy -Identity [id] -CatalogOnly

3. Move a Mailbox in a Batch
There may be cases where you need to keep track of mailbox moves both those which are in progress and to clear them afterward.

New-MoveRequest -Identity [id] -BatchName

4. Check Move Progress
The following command simply gets all the move requests and their statistics.

Get-MoveRequest | Get-MoveRequestStatistics

4. Clear a Move Request
In order to move a mailbox after a move request has completed or failed, you need to remove the request which can be done in bulk, individually, or by a batch name.

Get-MoveRequest | Remove-MoveRequest

or to remove a batch of requests already labeled...

Get-MoveRequest -BatchName [name] | Remove-MoveRequest

5. Determine Unified Messaging Enablement of a User
To check if a user is enabled for Unified Messaging, run the following.

Get-Mailbox | fl UME*

6. View Queues of all Hub Transport Servers
In some cases you may want to quickly view the queue status of all HT servers to determine if you have significant blockage along the transport pipeline.

Get-TransportServer | Get-Queue

7. Determine Active Calls on a UM Server
I find this one helpful as you can quickly see if a server is in use before performing a UM service reset or else use it for troubleshooting to see the status of a test call.

Get-UmServer | Get-UMActiveCalls

8. Determine Exchange Server 2010 Service Status
This command is helpful in quickly seeing which services are running particularly after a reboot.

Get-Service | Where {$_.DisplayName -Like "Microsoft Exchange*"}

9. Get Mailbox Sizes and Sort by Size

Get-Mailbox | Get-MailboxStatistics | where {$_.ObjectClass –eq “Mailbox”} | Sort-Object TotalItemSize –Descending | ft @{label=”User”;expression={$_.DisplayName}},@{label=”Total Size (MB)”;expression={$_.TotalItemSize.Value.ToMB()}},@{label=”Items”;expression={$_.ItemCount}},@{label=”Storage Limit”;expression={$_.StorageLimitStatus}} -auto

10. Check Autodiscover Settings

Get-WebServicesVirtualDirectory | fl InternalUrl,ExternalUrl
Get-EcpVirtualDirectory | fl InternalUrl,ExternalUrl
Get-OwaVirtualDirectory | fl InternalUrl,ExternalUrl
Get-OabVirtualDirectory | fl InternalUrl,ExternalUrl

Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri

Monday, February 13, 2012

HOW TO: Configure Lync Server 2010 and Tenor Analog Gateway

This post details the most concise steps I can articulate when configuring a Tenor voice gateway with Lync Server 2010.

STEP 1: Connect the gateway
After unboxing the unit you want to plug in the power and connect both a console and network cable. The device will seek out a DHCP server to obtain an address by default. You can search through your DHCP server's lease list by sorting the MAC address column and attempting to locate the Tenor's address or proceed with the next step.

STEP 2: Find the gateway
Download the Tenor Config Manager software by registering at NET's web site and install it on your PC used for configuring the device. The Tenor Config Manager software has an automatic detection feature which will find the gateway if it was able to obtain an IP address from your DHCP server. If you are unable to find the gateway using the software, use HyperTerminal or Putty to connect via COM port to the device to determine or set it's IP address.

NOTE: The default COM port settings are 38400/8/N/1/No flow control.

STEP 3: Update the firmware

1. Locate the latest firmware (it will come down as a zip file) from the NET web site and download it to your C: drive.
2. Unzip the contents of the firmware to a directory such as "c:\tenor-8port-firmware".
3. Click the START menu, click RUN, and type "cmd" and hit Enter.
4. Type "c:" and then Enter, then "cd \" and Enter, then "cd c:\tenor-8port-firmware" and Enter.
5. Type "ftp " and Enter. Type the username and password (default is admin/admin).
6. Type "bin" and Enter.
7. Type "hash" and Enter.
8. Type "prompt" and Enter.
9. Type "mput *.*" and Enter. This will copy all the unzipped files from the directory you started in which should have been "c:\tenor-8port-firmware". This will take a few minutes to complete.
10. Once complete type "bye" and Enter.
11. You now need to reboot the device. Do this with the Tenor Config Manager software or else Telnet into the device using the IP address you've learned and type "debug reboot".

STEP 4: Configure settings using the Wizard

1. Using Tenor Config Manager, locate the device using autodiscover and connect to it with the username and password (default is admin/admin). Alternatively if you know the IP address, you can use it to connect with the software.
2. The Config Manager software will prompt you to start by using the Wizard. This is the best choice as it walks you through the basic settings needed and only a few more manual settings will remain.
3. Click the Next button to start the Wizard.
4. Choose to "Specify a static IP" and click Next.
5. Set the IP address, Subnet Mask, and your Default Gateway. Leave the External NAT IP blank (all zero) and click Next.
6. Accept the default to "Manually Configure DNS Server Addresses" and click Next.
7. Enter the IP addresses of your DNS servers and click Next.
8. Click Next to continue with the dial plan settings.
9. Click Next to accept the default of "none" for the country.
10. Click Next to accept the default progress tone of "0-USA/Canada".
11. Click Next to begin the phone port configuration.
12. Click Next to accept the defaults of "Loop start/Forward Disconnect" and "FSK".
13. Enter a phone number for each port and click the Save button then the Done button.
14. Review your phone numbers for each port configured and click Next if you're satisfied with the changes.
15. Click Next to begin the VoIP Routing configuration.
16. Choose the default option of "SIP Only" and click Next.
17. Type the FQDN or IP address of your Mediation Server or pool name.
18. Modify the TCP port number to match the port used in your Lync topology. The default is not 5060 so be sure to set this correctly.
19. Click Next and Next again to bypass the registration page.
20. Click Next to begin the Idle Channel Configuration and choose "No" for disabling Phone/PBX-side channels then click Next.
21. Click Next then click Accept to submit all changes and reboot the gateway.

STEP 5: Configure Lync Server 2010 specific settings

1. Using the Tenor Config Manager software, connect to the Tenor device.
2. Click the Advanced Explore tab.
3. Expand the VoIP Configuration section, then expand the SIP Signaling Groups section and click on the SIP Signaling Group-1.
4. Turn off "Include Quintum Header" and "Allow Only Proxy Calls" then click the Confirm/OK button
5. Click the Advanced tab then change the Transport type to "TCP" and turn on the "Early Media Ring Tone" then click the Confirm/OK button.
5. Expand the Voice Codecs section and click on Voice Codec-1 then choose "G.711 Mu-law @ 64Kbps", then click the Confirm/OK button.
6. Expand the IP Routing Groups section, click on the IP Routing Group-default section, click the Fax/Qos tab, and change the "Fax Relay" and "Fax Modem Coding" both to "G.711 Mu-law".
7. Click the red/blue toolbar icon to submit all changes to the gateway.

DONE!




Saturday, January 28, 2012

TOP 10: Lync Server 2010 PowerShell Commands

I created this post in response to several requests from clients who wanted a go-to place to find the most commonly used commands and helpful commands for administering Lync Server 2010. In this post I cover the following commands:

1. Create and set up a Lync User
You will need an existing AD account for this command to function. Typically the SIP URI for users will follow their e-mail address. If not, you will need to specify the format to use or simply type it in. See the last help section of this post for more information on how to get effective help!

Enable-CsUser "Jason Shave" -RegistrarPool "poolname.domain.com" -SipAddressType EmailAddress

Next you may want to modify settings of the user such as their phone number (LineURI) or enable them for Enterprise Voice. These can both be set with one command as follows:

Set-CsUser "Jason Shave" -EnterpriseVoiceEnabled:$True -LineURI "tel:+17805551212;ext=1212"

2. Create a Common Area Phone
Common Area Phones (a.k.a. CAP's) are useful because you don't need an AD account to pre-exist as these objects are created as Contact objects in AD with the necessary properties set on them. You don't have to worry about resetting or setting passwords.

New-CsCommonAreaPhone -RegistrarPool "poolname.domain.com" -DisplayName "2FL Reception NE" -OU "OU=CAP,OU=Lync Server,DC=domain,DC=com" -DisplayNumber "+17805551212" -LineURI "tel:+17805551212;ext=1212"

NOTE: I've noticed a sort of bug with PowerShell in that if you specify the LineURI with an ";ext=" command in the string it won't tab-complete any other entries in the window so I typically leave that attribute to the end.

3. View or Assign a Policy/Dial Plan
Once you've created either a new user or CAP, you will need to set various attributes such as a Dial Plan, Voice Policy, Client Policy, Conferencing Policy, External Access Policy and so on.

To view all dial plans by name type:

Get-CsDialPlan | FL Identity
To view a voice policy, type the following: (since "Identity" is the only property beginning with the letter "I" we can use a wildcard character to save time)

Get-VoicePolicy | FL I*

To assign a Dial Plan to a user or set a voice policy to a CAP:

Grant-CsDialPlan "Jason Shave' -PolicyName EdmontonDialPlan1

Get-CsCommonAreaPhone "2FL Reception NE" | Grant-CsVoicePolicy -PolicyName NA-AB-Unrestricted

4. Assign a PIN
A PIN might not be as visibly necessary as you may think. Quickly though, a PIN is required for a non-tethered IP phone sign in, or a user joining a Lync audio conference as a leader from a non-Lync endpoint.

Set-CsClientPin "Jason Shave" -Pin 8675309
It is a good practice to set this PIN however users are able to create/set their PIN via the dialin simple URL accessible through the Lync client or the meeting request dialin phone number page (typically "dialin.domain.com").

5. Revoke a User Certificate
This one is more important than you may think as well. If you disable an AD account, and permit users to save their username/password, they will still be able to use Lync! I find a lot of people don't know this and it creates an interesting discussion with the security teams...

Revoke-CsClientCertificate "Jason Shave"

6. Move a User between pools or to an SBA

Move-CsUser "Jason Shave" -Target "poolname.domain.com"

7. Determine if a DID has been used
A common issue I see in environments where turnover is higher than normal is the recycling of DID's. When a user is disabled in Lync, their LineURI attribute in AD is still taken and cannot be reassigned. To find out the culprit, type:

Get-CsUser | Where {$_.LineURI -Like "*1212"}

The above command will find any LineURI attributes ending in "1212" such as "+17805551212" or "+17805551000;ext=1212".

8. Check CMS replication health
Any change to the CMS database such as a voice route, dial plan, or voice policy will result in the change being propagated to all Lync servers in the topology. Often times a change is made resulting in a test being performed (i.e. fixing a broken route). You will want to validate the change has been replicated to all servers in the topology before testing....and give it an extra 60 seconds after synchronization has been completed too!

Get-CsManagementStoreReplicationStatus

Alternatively if you have a very large topology, you can be more specific as follows:

Get-CsManagementStoreReplicationStatus | Where {$_.UpToDate -ne $True}

9. Determine number of users enabled for Enterprise Voice

(Get-CsUser | Where {$_.EnterpriseVoiceEnabled -eq $True}).Count

Getting more complex, lets try to count the total number of EV users and CAP's and get a combined total. In the following example we use the ";" command in a one-liner to initiate a carriage return. We also store the outcome in a variable called "$str1" and "$str2":

$str1 = (Get-CsUser | Where {$_.EnterpriseVoiceEnabled -eq $True}).Count; $str2 = (Get-CsCommonAreaPhone).Count; $str1 + $str2

10. Getting help from PowerShell 
I've found the following tips helpful when trying to find out what PowerShell can do for me...

To get help on a command such as Get-CsUser type:

Get-Help Get-CsUser

NOTE: Use the TAB key on your keyboard when typing in PowerShell to complete long commands. As an example, you wouldn't want to type these comands every time:

Get-CsManagementStoreReplicationStatus
Get-CsUserReplicatorConfiguration
Get-CsEnhancedEmergencyServiceDisclaimer

For example, type "Get-CsMan" for "Get-CsManagementStoreReplicationStatus"

Sometimes you want examples of a command such as "Get-CsUser" so in this case you would type:

Get-Help Get-CsUser -Examples

If you forget a command or want to know all the commands associating with setting a user property, try:

Get-Command Set-CsUser*

Again, you might want to know what a specific parameter for "Set-CsUser" does such as AudioVideoDisabled:

Get-Help Set-CsUser -Parameter Au*

Hope this helps! Feedback is always appreciated so let me know if you note a mistake or would suggest alternative top 10's. Cheers!

HOW TO: Copy Quintum Tenor Gateway Configuration

This post shows you how to copy the configuration from a Quintum Tenor analog voice gateway for the purpose of either backup or restoration. In my case I used this process in the deployment of several similarly configured gateways at a customer site instead of starting from scratch each time.

First a warning or three....NEVER copy a gateway configuration from a non-like device to another using this method. Be sure you copy the same configuration to the same type of device with the same port configuration every time.

Second, be sure you have updated the firmware of your target device to the same level of your source device.

Third, this method of copying a configuration from one device to another is officially not supported by NET. Use at your own risk!!

STEP 1: Logging into the device
The default login username for the Tenor gateways is "admin" with the password being the same. You can FTP to the device using Windows Explorer or via Command Prompt.

Using Windows Explorer is as easy as typing ftp:// and hitting enter followed by the username and password.

STEP 2: Copying the configuration from a source device 
Once you've gained access to the device, double-click the "cfg" folder and then double-click the "db" folder. You should see three files called "hw.txt", "db.txt", and "ipconfig.txt". Simply copy these files (if you're using Windows Explorer use CTRL-C) and paste them (CTRL-V) to a safe location you will remember.

The files are very small and can be stored just about anywhere. Be sure to place them in a directory with a name matching the make, model, and port density.

NOTE: If you want to modify the configuration of these files, please use the command-line or the Tencor Config Manager software. NEVER EVER modify these files while they're on the gateway (in flash memory).

STEP 3: Modify the configuration before deployment
Now you're ready to modify the configuration and prepare the files for deployment to your target device. The most obvious configuration change you will make will be the IP address of the device to prevent a duplicate IP on the network when you deploy the target device. This can be done by opening the "ipconfig.txt" file on your PC (again, never on the flash memory of the target or source device).

Make a copy of your backed up files to a new directory as these will be your working copies. Now, simply open the "ipconfig.txt" file using Notepad and modify the parameters necessary. As an example, please see the image below:


The two "set" commands will change the IP address and subnet mask while the "change" command highlighted above will change the default route (default gateway ip). To modify the DNS settings for the device you need to open the "db.txt" file and modify the following settings:


Once complete, save the file(s).

STEP 4: Copy the configuration to your target device
If you still have an open connection to your Tenor device, close it and open a new connection to your target device using the correct username and password. Since the new device may be new out of the box, you can use the Tenor Config Manager software to locate it or else use a console cable to determine the IP address.

As you can imagine, the process for copying is the same as you would any other file to a Windows folder. Copy/Paste the files into the /cfg/db location of the target device and overwrite the files.

Now you can safely reboot your target device and attempt to connect to it via FTP using the new address.