RSS Subscription 168 Posts and 2,769 Comments

Archive for June, 2013

Lync 911 Location Based Policies Based on Network Site

Lync 2010 introduced Enhanced 911 dialing.  This has been vastly documented and therefore, I will not be blogging on how Enhanced 911 works.  For a great blog post on this, please see the following TechNet blog post from Jens Trier Rasmussen here.

One thing Jens does touch on is using Network Sites for using the Location Policies.  My intent of this blog post is show you how to configure users so their Location Based Policy can change based on what Network Site they are assigned to.  This can be beneficial for both E911 deployments and 911 deployments.  Where it is beneficial in non-E911 deployments is where you want users to always route a local PRI/POTS when they switch Network Sites. This will be beneficial for organizations who will not be deploying Enhanced 911.

Configuration

The first thing we will want to do is get all of our Network Sites and Subnets defined. I have created two scripts for this that will help you automate this process.

  • New-CSMultiRegionNetwork.ps1
    • Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
    • Export Data to CSV
    • Allows you to specify Lync Network Regions and their corresponding Lync Central Sites
    • Allows you to assign Location Policies to Sites (Note: The Location Policies need to be created beforehand as the script will not create Location Policies)
    • Allows you to assign Bandwidth Policies to Sites (Note: The Bandwidth Policies need to be created beforehand as the script will not create Bandwidth Policies)
    • Will create the Lync Network Regions and assign them to the corresponding Lync Central Site as defined in the CSV
    • Will create the AD Site in Lync Network Sites
      • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
      • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
      • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site
      • It will assign the Lync Bandwidth Policies and/or Lync Location Policies as defined in the CSV
  • New-CSSingleRegionNetwork.ps1
    • Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
    • Will create the AD Site in Lync Network Sites
      • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
      • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
      • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site

After creating the network sites with subnets attached, we can see all that data has been imported into Lync.  The client subnet we will be testing on will be 192.168.1.0/24 which is assigned to the Chicago Site.

L15911Local01

What we now need to do is create a PSTN Usage which we will be assigning to the Chicago Voice Policy.  This PSTN Usage will be assigned to a 911 route.  That way, my test user will be in the Chicago Voice Policy which will have the 911 PSTN Usage which will allow them to utilize the 911 route.

Go into the Chicago Voice Policy that will be assigned to your test user account. Go ahead and click New under PSTN Usages.

L15911Local02

Go ahead and give the PSTN Usage a name.  Because this will be for local 911 routes, give it a prefix of Chicago.  In my example, I name it Chicago-911. Then click New for Associated Routes.

L15911Local03

Just like with our PSTN Usage, we’ll want to prefix the 911 route with the site name because the intent of this entire configuration is so users route out a local trunk.  It’s site-based routing.   Our 911 numbers will route out as +911.  I will show you why later.  In our example, the 192.168.1.99 trunk would route our +911 number over to this gateway which is a gateway located in Chicago.

L15911Local04

We can now see our Voice Policy for Chicago contains the Chicago-911 PSTN usage.  And the Chicago-911 PSTN usage is assigned to the Chicago-911 voice route.  This is what allows Chicago Voice Policy users to be able to hit the Chicago-911 Route.

L15911Local05

Now it’s time to create the Location Policy. You will need to create a user policy.  Site policies will not work for this type of automation.  This Location Policy will be assigned to our Chicago Network site which is what allows the automation to happen.

In our Location Policy, the below configuration is sufficient since we’re not using Enhanced 911.  We’re just leveraging Location Policies that will be assigned to Network Sites so when you hop from one site to another, you’ll get a new Location Policy.  This means you will have one Location Policy for every site.  And the Location Policies for each site will have their local PSTN Usage to ensure when a person goes from one site to another, they’ll get a new Location Policy so if they dial 911, it will use a different PSTN Usage which will route out the local trunk for that site.

The E9-1-1 dial number will automatically have a + added to it when it gets sent to the route.  This is the reason why our route pattern was +911.  The E9-1-1 dial masks, when entered, are automatically normalized to the E9-1-1 dial number.  So for example, if I enter 9911 or 4411, it will automatically normalize to +911.  And if you need multiple dial masks, you can use a semicolon.

L15911Local06

Go back to the Site, and specify Location Policy as Chicago-911.  Now, anytime someone who is in this site (192.168.1.0 or 192.168.2.0), will automatically get this Location Policy.

L15911Local07

Make sure your user has the Chicago Voice Policy assigned.

L15911Local08

Now before logging out, lets take a look at what happens if I try dialing 911.

L15911Local09

We see that no normalization has occurred.  But after signing out and back in, we can see that it will now display +911.  That means that the location policy has correctly been applied to the account.  We can also see that the 9911 and 4411 is also working.

L15911Local10

That’s all there is to it.  However, what happens to users who happen to fall onto a subnet that happens to not be assigned to a site?  Thankfully, there is a fallback.  In the user properties, assign the user to a Location Policy that is in their home site.  What happens is, if the Network Site they are on has a Location Policy, that Location Policy is handed back to the user.  If they happen to not be assigned to a Network Site due to the subnet they are on not being assigned to a Network Site, they will utilize the Location Policy assigned to their user account. You can see Jens Trier Rasmussen explaining this in this TechNet Post here.  Specifically, Jens calls this out in the “Configuring Location Policy” section.  Jens states the following:

  • If the subnet (defined by the cmdlet New-CsNetworkSubnet) is associated with a network site (defined by the cmdlet New-CsNetworkSite) and that network site is associated with a LocationPolicy, this location policy is returned to the client.
  • If the subnet is unknown or if the network site isn’t associated with a LocationPolicy, the location policy associated with the user is returned.
  • If the user is not associated with a location policy, the global location policy is returned.

Therefore, it is recommended that if my Client User 1 is primarily based in Chicago, assign that user the Chicago Location Policy.  When they travel and they’re  not on a network site, their 911 will still route, even if it’s not a trunk that is local to their current location.  But at least they’ll hit the 911 PSAP who can then ask for the user’s address and route accordingly.  This is where Enhanced 911 would be better.  But if Enhanced 911 is not used, it is very important to make sure all the appropriate subnets are added to the Network Sites so you don’t have to revert to the fallback mechanism and potentially have a user route out of a trunk that is not local.

To assign the Location Policy to the user as part of this fallback mechanism, go into the Users section, open up that users settings, and choose that user’s Location Policy.

L15911Local11

Share

Updating SQL 2012 Express to SP1 on Lync 2013 Servers

General Information

When installing Lync 2013 Servers, as a part of the install, SQL Express 2012 RTM is installed.  In fact, there are several instances on Lync 2013 Front End Servers that get installed. The following lists what SQL Express instances get installed on what servers:

Standard Edition Front End Server

  • RTCLocal
  • LyncLocal
  • RTC

Enterprise Edition Front End Server

  • RTCLocal
  • LyncLocal

Now let’s say your Front End Servers are not installed yet.  There’s a great way to pre-install your SQL 2012 Express instances with SP1 instead of letting the Lync 2013 Deployment Wizard install SQL.  If you pre-install these SQL 2012 Express SP1 instances, Lync 2013 deployment wizard will see that the prerequisite of needing SQL 2012 is met, and will forgo the need for installing any SQL 2012 Express instances and will utilize the pre-installed SQL 2012 Express SP1 instances.  For more information on this, please see this TechNet blog post here.

Lync MVP, Pat Richard, has created an excellent script for all sorts of automated tool downloads/installs as well as prerequisite installs.  His script will take care of the SQL 2012 Express SP1 instances for you as well.  His script is here.

Let’s say you didn’t know about Pat’s script or that you could preinstall SQL 2012 Express SP1 and you have already installed Lync 2013 Front End Servers using the SQL 2012 Express RTM code.  I will show you how to upgrade your SQL 2012 Express RTM instances to SQL 2012 Express SP1.

Installation of SQL 2012 Express SP1 x64

First, you will need to download the SQL 2012 Express SP1 x64 bits from here.

Once these bits are downloaded, open a Command Prompt and navigate to where these bits are downloaded.

On an Enterprise Edition Server, you will want to run the following two commands:

SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=LYNCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms

On a Standard Edition Server, you will want to run the following three commands:

SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=LYNCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTC /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms

In my environment, I have initiated the update for the RTCLocal instance.  Below are a few screenshots of the update process in action.

L15SQLUpdate01

L15SQLUpdate02

L15SQLUpdate03

L15SQLUpdate04

Validating SP1 Installation

Once the install is complete, I’m sure you’ll want to validate the instance has been updated to SP1.  Fortunately, an excellent script for this is provided here.  Once downloaded onto your server, you will have to run the following command to allow this unsigned script to be run:

Set-ExecutionPolicy Unrestricted

Go ahead and execute the getInfo-SqlServer.ps1 script.

As expected, we see the RTCLOCAL instance has successfully been updated to SP1.

L15SQLUpdate05

Share

How Anonymous Relay works in Exchange 2013

This article is to provide you, the reader, the knowledge on how to properly create an Exchange 2013 Relay Connector.

In Exchange 2013, I am utilizing a multi-role server that has both the Client Access Server and Mailbox Server roles. We’ll want to head to the mail flow section in the Exchange Administration Center (EAC) that you can access by going to https://OWA.domain.com/ECP.

E15Relay02

Once in this mail flow section, we’ll click the tab called receive connectors which will allow us to see all receive connectors that exist.

E15Relay03

As you can see, there are connectors for FrontendTransport and connectors for HubTransport.  FrontEndTransport belongs to the Client Access Server Role and the HubTransport role belongs to the Mailbox Server role.

Let’s take a look at the “Default B-E15DAG1” receive connector that belongs to the HubTransport role  as well as the “Default Frontend B-E15DAG1” that belongs to the FrontendTransport role.

Taking a look at the “Default FrontEnd B-E15DAG1”, we can see that the connector listens on port 25 as we would expect.

E15Relay05

Taking a look at the “Default B-E15DAG1” receive connector, we can see it listens on port 2525 which is something we haven’t seen before.

E15Relay04

All mail flow should come into the Frontend Transport which then delivers it to the appropriate mailbox server where the mailboxes exist.  On a multi-role server, these two roles cannot utilize the same ports as they are two different services.  What this means is, when creating a relay connector, this connector must be created on the Client Access Server role that owns the Frontend Transport because this service is the service that owns port 25.  If you try to create a receive connector on the Mailbox Server role that owns the HubTransport service, mail flow may work temporarily, but it will eventually fail due to both the FrontendTransport and HubTransport services fighting each other for port 25.  Obviously if the Client Access Server and Mailbox Server roles are on different servers, it’s not an issue.

To create our relay connector, we’ll choose the + symbol to create a new Receive Connector.

E15Relay06

Give the connector a name and be sure to choose Frontend Transport and Custom. Click Next.

E15Relay07

The default settings here are fine.  We want port 25 due to what I mentioned above. Click Next.

E15Relay08

In the remote network settings, it is important to ensure that you remove 0.0.0.0-255.255.255.255.  We want to explicitly define what servers are allowed to relay to ensure our server does not turn into an open relay for everybody.  In my case, I am going to add 192.168.50.2 which may be a printer, custom application, etc…  But the server that owns 192.168.50.2 would need to relay.  Once this is done, click Finish.

E15Relay09

Once the relay connector is created, open its properties, go to security, and make sure you check Anonymous Users.

E15Relay10

So what really happens when you place a check mark in the Anonymous users group in the above screenshot?  A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server.  This is NOT the case.

When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:

  • Ms-Exch-SMTP-Submit
  • Ms-Exch-SMTP-Accept-Any-Sender
  • Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
  • Ms-Exch-Accept-Headers-Routing

So, as you can see, there is no Ms-Exch-SMTP-Accept-Any-Recipient permission added by default.  Because of this, users will NOT be able to relay off your Exchange Server by default.

To activate Anonymous users to use this connector for relaying, you must issue the following command: Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector.  Once this is done, any server IPs you added to the Remote Network settings will be allowed to relay off your server utilizing port 25.

E15Relay11

Now you may be thinking, why should I create this new connector?  Well, Exchange will always look to see how specific you are on a connector.  So let’s say we have a SharePoint Server at 192.168.119.150.  We would create a relay connector and allow ONLY 192.168.119.150 to relay.  So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors.  One being the Default Receive Connector and one being the Relay Connector.  The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150.  Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).

Now, for servers that will have a lot of relay traffic, there are some more steps you need to do on your Receive Connector.  If you see that you have mail flow issues where things periodically work with relaying and sometimes they don’t, it’s recommended to run the following commands on your Relay Connector.

Set-ReceiveConnector -identity “Relay Connector Name” -TarpitInterval 00:00:00

Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionTimeout 00:30:00

Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionInactivityTimeout 00:20:00

Set-ReceiveConnector -identity “Relay Connector Name” -MaxAcknowledgementDelay 00:00:00

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnection 10000

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPercentagePerSource 100

Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPerSource unlimited

So in my case, I would run the following command which would allow me to do Get-ReceiveConnector and pipe into Set-ReceiveConnector to make all the modifications in one command:

Get-ReceiveConnector -Identity “Relay Connector Name” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited

E15Relay12

If you are wondering what the default settings were, I ran the following to view the defaults before running Set-ReceiveConnector.

E15Relay13

 

Share