You have just finished installing Lync Server 2013 onto Windows 2012 R2 and you start the Lync Server Management Shell only to spend the next few minutes (or hours) staring at a little back box. If you are lucky it will finish loading in a few seconds, however for you unlucky few you can end up staring at the black box forever. Now a quick workaround for this is to just use the default PowerShell shortcut as the Lync Server cmdlets are automatically loaded in Windows Server 2012 R2. However, if you are like me you want to know just what is wrong and it’s eating away at you from the inside.
The answer is very simple. There is a problem with the way the Lync Server Management Shell shortcut is generated and all that you will need to do is add the missing double quotes (“) to the end of the Target field in the shortcut.
- Click the Start button
- Start typing “Lync Shell” to display the Lync Server Management Shell shortcut
- Right click the shortcut and select “Open File Location“
- Right click the Lync Server Management Shell shortcut and select Properties
- Edit the Target field and add the missing double quotes (“) to the end of the command
- Click OK
Since we are editing the root shortcut the change will affect all administrators that login to the system. Translation, you will only have to make the change one time.
Special thanks to Korneel Bullens for pointing out this fix to me.
It is becoming more common place to see requests from customers who need to place a firewall between Lync Pools. Maybe the servers are separated by large geography or in different datacenters or the InfoSec team requires firewalls between applications (zoning). Now Microsoft has published very good information on what ports are needed for the different roles and services in Lync Server and Client. However, what about other Windows services that Lync uses? Troubleshooting firewalls and ports is a pain and can lead to extra work when something doesn’t work as expected. One of those key services in particular is DCOM.
The DCOM ports are used in conjunction with RPC (135) for moving users, user replication synchronization and address book synchronization. Now Microsoft does states that you need port 135 in their TechNet article and the protocol does say DCOM and RPC. However, most people will assume that 135 is all you need. That’s where the mistake happens. Now most Network and InfoSec teams are not going to be too happy when you call them up and say that you need port 1024-65535 opened up between your two pools. In fact, we know what they will say.
Let’s take a typical move-csuser request. A NetMon trace will show that their is an initial RPC request occurs on behalf of the svchost.exe process over port 135 however the actual “work” will occur over DCOM and utilize the high port range. If this port range is blocked due to a firewall you’ll get an error from the PowerShell command saying that DCOM isn’t available.
To address the large number of ports DCOM uses by default, Microsoft has published a procedure to configure DCOM to work with firewalls. Leveraging the procedure found here one can modify the registry and restrict DCOM to use a specific port range. Microsoft recommends a minimum of 100 ports for this protocol. That’s much less than what we started out with. You can get the articles below along with some of my favorite tools for network troubleshooting.
In this example ports 5000 through 5100 inclusive have been arbitrarily selected to help illustrate how the new registry key can be configured. This is not a recommendation of a minimum number of ports needed for any particular system.
- Add the Internet key under:
- Under the Internet key, add the values “Ports” (MULTI_SZ), “PortsInternetAvailable” (REG_SZ), and “UseInternetPorts” (REG_SZ).
For example, the new registry key appears as follows:
Ports: REG_MULTI_SZ: 5000-5100
PortsInternetAvailable: REG_SZ: Y
- Restart the server. All applications that use RPC dynamic port allocation use ports 5000 through 5100, inclusive. In most environments, a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.
Articles & Tools
If you are having problems with certain features on the Lync Web App and need to enable logging you can use the following simple procedure to enable verbose logging in the Lync Web App. To enable logging you can follow this simple procedure as outlined here. But if you are really having a problem, the default logging level may not be enough. So how to we enable verbose logging in the Lync Web App?
Force the Lync Web App client
Append ?sl=1 to the end of the meeting invite to join any meeting using the LWA instead of the Lync client.
Enable verbose logging
Append ?log=full to the end of the meeting invite.
Force the LWA client and verbose logging
That’s easy, just use the & to join the two strings together.
Where are the logs?
The logs that LWA creates are stored here:
The file you are looking for is:
Where x is a number, usually 0 or 1. Opening up the file, you will see a whole bunch of information including information about WebTicket, MRAS, and ICE candidates among other information.
By default Lync installs SQL Express and the local databases onto the system drive during a Lync install. This is typically ok if only one drive exists on the server however, what if you have another drive which is dedicated to applications, a non-system drive. Lync will automatically move the Lync local databases to a non-system drive but SQL Express itself stays on the system drive. If there are three or more drives installed there is a way to control even further where the Lync local databases are stored.
Jens has a nice write up on installing the local databases to a separate drive that you can read here.
This still doesn’t solve the problem of installing SQL Express to a non-system drive. If you try to install SQL Express manually there is no guarantee that the install willpass the pre-requisite checks. After much trial and error along with a gentle parsing of the log files I was able to extrapolate the following command to install SQL Express to a non-system drive. Modify the following parameters to fit your build.