Lync

Cannot login to Lync Control Panel “Unauthorized: Authorization Failed”

When accessing the Lync Control Panel you may receive this error:

 

image

One possible resolution to this issue is to make sure that your CSCP URL is in your Trusted Sites List. If you have already done this and are still receiving this error, head to the Lync Event Logs on your Lync Front End.

In my case there were a string of LS Remote PowerShell errors each time I attempted connecting to the Lync Control Panel.

The first error from the event logs that I saw was this:

 

Log Name: Lync Server

Source: LS Remote PowerShell

Date: 7/29/2011 7:22:46 AM

Event ID: 35007

Task Category: (3500)

Level: Warning

Keywords: Classic

User: N/A

Computer: LYNCSE1.contoso.local

Description:

Remote PowerShell cannot create InitialSessionState.

Remote PowerShell cannot create InitialSessionState for user: S-1-5-21-1369671878-2169378501-2720954840-500. Cause of failure: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Cause: Remote PowerShell can fail to create InitialSessionState for varied number of reasons. Please look for other events that can give some specific information.

Resolution:

Follow the resolution on the corresponding failure events.

This error shows that it could not connect to the SQL Server due to a network error.

 

Log Name: Lync Server

Source: LS Remote PowerShell

Date: 7/29/2011 7:18:51 AM

Event ID: 35005

Task Category: (3500)

Level: Error

Keywords: Classic

User: N/A

Computer: LYNCSE1.contoso.local

Description:

Remote PowerShell cannot read the RBAC Roles information from the store.

Remote PowerShell encountered problem when trying to read the RBAC Roles information for the user. Cause of failure: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Cause: The failure may have happened due to some permissions issue in reading the management store.

Resolution:

Make sure that the server is domain joined machine and able to query the active directory.

This error shows that there were issues retrieving my RBAC information from the CMS.

The resolution for this issue ended up being to start the SQL Browser Service on the Lync Front End.

This service provides connecting users with the ability to discover proper connection information when attempting to make a SQL Connection.

After starting this service, logins to the Lync Control Panel worked again.

image

(2707)

Posted on by Randy Wintle in Lync, Lync Server 2010, Networking, Unified Communications 6 Comments

Deploying DSCP QoS On Server 2003 R2 and Server 2008 R2

This is a brief post to summarize my experiences with deploying quality of service in a recent deployment.

In this engagement, the customer had existing OCS 2007 R2 infrastructure, these were running Server 2003 R2 with the latest service pack, and were running on HP hardware with Teamed NICS for redundancy, not load balancing.

When attempting to deploy packet tagging on the servers using the QoS Packet Scheduler and related policies, packets would not tag at all. When breaking the NIC Team packets would tag, and on any servers without a teamed NIC the same policies worked fine. This was identified as a known issue with 2003 R2 and Teamed NICS.

The good news, is that while we are upgrading to Lync Server 2010 their new servers are running Server 2008 R2 and on similar hardware with Teamed NICS. As of today we have tested QoS deployed using the packet scheduler and related policies and it does work with the Team.

(28)

Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, Networking, OCS 2007 R2, Unified Communications Leave a comment

Deploying a Lync SBA? Watch out for port 444 (Updated with more ports)

As Lync deployments start ramping up, we are starting to notice a few gotchas in documentation and deployments. One thing that has come up a couple of times is deploying a Lync SBA in a branch site with a firewall between the Datacenter and branch office.

The firewall ports required for the SBA are not well documented, particularly one that is very important to making the SBA Work.

Port 444 TCP is required for front end to SBA communications, below is the only documentation I have found on it so far in the CHM.

Front End Servers

Front-End service

444

HTTPS

TCP

Used for HTTPS communication between the Focus (the Lync Server component that manages conference state) and the individual servers.

This port is also used for TCP communication between Front End Servers and Survivable Branch Appliances.

 

I reviewed the Lync 2010 Workloads Poster and it is not showing this port as well. However, I have requested an update which we will hopefully see soon.

So, very important, open port 444 TCP between your Data Center and your Branch Office or users will not be able to register against the SBA. Reference of the ports can be seen below.

 

image

As a follow up, one of my colleagues pulled together the full list of firewall requirements for branch users. As many enterprises have firewalls between branch and central sites, this list becomes very important. Look for a workloads poster focused on firewalls from Microsoft soon, but hopefully this comes by then. Credit for this list goes to Peter Pawlak at UnifySquare:

SBA (ASM side) <-> Central Site Pool(s):

· TCP/5061 (both ways)

· TCP/444 (both ways)

· TCP/445

· TCP/448

· TCP/5062-5065

· TCP/5072-5073

· TCP/5076

· TCP/5080

(NOTE: I’m not 100% positive that ports in RED are really needed)

SBA -> Monitoring Server(s) (to support MSMQ)

· TCP/135

· TCP/389

· TCP/1801

· TCP/2101

· TCP/2103

· TCP/2105

SBA (ASM side) <-> Exchange UM servers

· TCP/5061

· UDP/<ExUM media port range>

SBA (ASM side) <-> Edge Server(s):

· TCP/5061

· TCP/5062

CMS servers -> SBA (ASM side) (for local config store replication)

· TCP/4443

· TCP/444

· TCP/445

Branch Clients -> SBA (ASM side):

· TCP/5061 (client->SBA)

· TCP

· UDP/<media port range> (assumes no media bypass)

Branch Clients <-> SBA (GW side):

· UDP/<media port range> (assumes media bypass will be used)

Branch Clients -> Central site Pool (must be pool in site associated with Branch site)

· TCP/8057 (and TCP/8058 if using Lync’s legacy data conf service)

· TCP/5061 (to allow failover to backup central site)

· TCP/<app share conf MCU port range>

· UDP/<A/V conf MCU port range>

Branch Clients -> Central site Pool Web service HLB VIP (pool in site associated with Branch site)

· TCP/443

· TCP/80 (needed by Lync PE devices)

Branch clients <-> Clients & Mediation servers/services in other sites

· UDP/ <media port range>

· TCP/<media port range>

Branch clients <-> Edge servers (running media relay)

· UDP/3478

· UDP/ <media port range>

· TCP/443

· TCP/<media port range>

Branch clients -> Exchange UM servers

· UDP/<ExUM media port range>

Branch clients -> Exchange CAS servers (for EWS)

· TCP/443

(2591)

Posted on by Randy Wintle in Lync, Microsoft, Networking, Unified Communications 8 Comments

Configuring Forefront Threat Management Gateway for OCS 2007 R2 Part 1

The reverse proxy installation can be confusing if you have never done it before. In this scenario I will be standing up a new server to replace my ISA 2006 SP1 Server. I will create all of the rules from scratch and walk through the installation.

Network Configurations

The most important part of this reverse proxy setup is the networking configuration. It is recommended to have at least two network interfaces on the TMG server, in my case we have a network card in the DMZ with public IP addresses and one on the internal network. Depending on your actual network configuration this could be different.

An important thing to note is that in windows you can have multiple network interfaces on different networks, but not multiple default gateways. Because of this, we need to choose an adapter with the default gateway, and one without any gateway, using manual routes to get to internal resources. In most scenarios it would be ideal to assign the default gateway to your internet facing NIC, this is because it is impossible to enter manual routes for all possible internet traffic. The internal or DMZ NIC typically has no gateway, but we will assign persistent routes for the internal networks.

In my case, the NIC is directly on the internal network, so servers can communicate directly on the same subnet with no routing needed. However, I will show you how to configure these routes for another internal network to simulate the need to route. In an edge server configuration you will need routes for the desktops as well as servers, so it is important to know how to do it.

In my situation, the address spaces involved will be as follows:

Server LAN: 10.117.117.0

Desktop LAN: 10.1.2.0

DMZ: Public IP addresses

Because my TMG server has a NIC directly on the 10.117.117.0 network I do not need a route for that network, but in order to talk to the 10.1.2.0 network, I will need persistent routes. To see the route setup on your server:

Open a command prompt as administrator

Type Route Print and hit enter

image

Your output should resemble something like the picture above. Note the 10.117.117.0 network has routes directly on that link, and the default gateway is set to our public interface.

To add a route to the 10.1.2.0 network type the following at the command prompt and hit enter:

route add –p 10.1.2.0 MASK 255.255.255.0 10.117.117.2

Where 10.117.117.2 is the router on your network.

If you see OK! after you hit enter, the command took succesfully.

image

This means any requests for that network are in the route table, and are to go to 10.117.117.2, which will happen via the 10.117.117.106 interface, or our Internal interface.

This is a fairly basic network configuration, in most environments it will be more complex and involve more subnets. However hopefully this gives you a good idea of how to setup the network in your environments.

TMG Installation

Before I get started, the diagram below will show the basic environment as it relates to the reverse proxy and my OCS Pool.

OCSRP

Update the server with the latest patch levels, and then launch the TMG Install. You will get a screen prompting you to Perform Updates, Run the Preparation Tool, or Run Installation Wizard.

image

Select Run Preparation Wizard. This Wizard will add the server role required for TMG to operate on the server. As you click through the installer you will have to choose a type of installation, choose Forefront TMG services and management for a complete install.

image

Let the wizard run, it will install all roles and services needed. When completed you will be presented with a screen that shows Success or Failure, Click Finish and Launch the TMG Installation Wizard.

image

The installation wizard will have a few defaults to accept, and then you will be asked to choose your internal network ranges. Choose Add, then choose Add Adapter. Select the Internal network interface on the server. If you previously entered persistent routes you will notice those subnets show up as being associated with that adapter as well.

image

Hit OK twice and your window should look something like this:

image

The address ranges should reflect your DMZ adapter address and any internal networks you will be routing to.

Hit Next twice to acknowledge the services that will be restarted during the install. The next page will notify you that forefront will create rules to allow domain traffic to domain controllers listed

image

If this information looks correct, hit Next, then Install and let the installation complete.

image

The installation will take some time to complete, but once it is done you should see this screen, click Finish to launch the configuration wizard.

image The initial configuration wizard will then launch. Note: You can import ISA 2006 XML configuration files to this if you do not wish to recreate your rules. I am going to start from scratch however to show the whole configuration process.

image

Run the wizard to configure network settings. This setup is an Edge Firewall configuration. Choose Edge and click next.

image

Choose your internal network adapter to be associated with the LAN. You may also enter routes here, I am not sure if this makes the previous routes entered not needed, but I will do more testing and update the blog if that changes.

imageThen choose your external adapter, in my case labeled DMZ

imageConfirm the information, and choose Finish.

imageJust to continue through the wizards, although not necessary needed, you can choose Configure System Settings which basically has you confirm the computer and domain settings.

imageimage

The next step is to define Deployment Options which chooses your license information, and update settings. I will not cover that in this post.

image

Once you launch the TMG Console, you will notice a somewhat familiar interface with a whole lot of new features.

image

OCS Website Publishing Rules

Before starting with any OCS rules you should import the public certificates for your OCS Web Farm.

You should have a standard SSL certificate with a common name that matches the External Web Farm FQDN you specified during setup, or that name should reside on a UCC certificate. Either way, you must import that certificate into the Local Computer store with a valid Private Key before it can be used with ISA.

To do so, open the certificates MMC.

Right click on the Personal certificates store and choose All Tasks –> Import

imageIn the certificate import wizard, select the certificate file for your web farm certificate.

imageHit Next, enter the password used when exporting the certificate private key.

imageHit Next, choose to place the certificates in the following store, Personal should be selected.

image

Hit Next, then Finish. Your certificate should now be ready for use with ISA. 

For OCS, we are simply concerned with Firewall Policies, there are a lot more features to TMG 2010, which I hope to cover at a later date.

Select Firewall Policies, and choose Publish Web Sites from the tasks pane on the right

imageEnter a name for the rule such as OCS Web Components

imageHit Next, for a rule action choose Allow.

imageHit Next, choose Publish a single website or load balancer.image    Hit Next, choose Use SSL to connect to the published web server or server farm.

imageHit Next, for the internal site name enter your internal web farm FQDN, usually the pool name. If the ISA server cannot resolve that pool record, you can specify a computer or IP address as well.

image 

Hit Next, for the path enter /* to allow all traffic to the pool for the various services.

imageHit Next, for the public name, enter your external web farm FQDN. You should have set this during install, or manually configured later.

image  Hit Next, choose New to create a new web listener. Enter a name for the listener such as OCS Web Listener.

imageHit Next, choose require SSL secured connections with clients.

imageHit Next, for the web listener IP address choose the External Network, hit Select IP Addresses.

Choose the radio for Specified IP Addresses on the forefront TMG Computer in the selected network. 

Select the IP address that will your web farm FQDN dns A record points to, and choose Add so it shows in the selected IP addresses column.

imageHit Ok, then Next. For the Listener SSL Certificates make sure Assign a Certificate for Each IP Address is selected.

Highlight the IP address and choose Select Certificate…

The next page will show you the valid certificates installed to the local computer personal store on your server. Choose the certificate for your OCS web Components and choose select.

imageHit Next, for authentication settings choose No Authentication from the drop down menu.

image

Hit Next twice, choose Finish to complete the listener configuration, you will be brought back to the web site publishing wizard with the new listener selected.

Hit Next, for authentication delegation choose No Delegation, but client may authenticate directly.

imageHit Next twice accepting the defaults, and choose Finish to create the rule.

Make sure you hit Apply to actually commit the rule.

imageOnce the rule is created, TMG 2010 has built in tools to test that rule for you. Right click on the rule and choose Properties. Then select Test Rule.

imageIf everything is working, including certificates, and authentication access, you will see all green. Any errors will have descriptions of the problem and how to fix it.

image   A new feature of TMG 2010 is a path ping, that basically is a traceroute of the path taken to get there. Use this to verify your routing configuration from before.

image 

Now that this rule has been configured and you have an external DNS A record pointing to your External Web Farm FQDN, your users should be able to access the OCS web components remotely.

In the next post I will outline configuring TMG 2010 for Communicator Web Access.

(214)

Posted on by Randy Wintle in Forefront TMG 2010, Networking, OCS 2007 R2, Server 2008 R2, Unified Communications 9 Comments

Server 2008 R2 Hyper-V Host Cannot Browse Network

Usually I am posting Microsoft UC Related problems, however this issue relates to 2008 R2 with hyper-v. We added a new host to our environment and could not browse server shares, or browse the shares that existed on the new host.

Luckily, this was a very easy fix, and I guess the point is, always start at the bottom before digging too deep into issues. I over complicated the issue, but eventually found that the VM NIC, being shared by the host and the virtual machines, did not have any of the network discovery services enabled on the actual adapter.

 

image

The key settings were:

Client for Microsoft Networks

File and Printer Sharing for Microsoft Networks

Link-Layer Topology Discovery Mapper I/O Driver

Link-Layer Topology Discovery Responder

These services are usually enabled by default which is why the issue was a bit weird, but just something to look out for when working with Hyper-V and Virtual Network Adapters.

(101)

Posted on by Randy Wintle in Hyper-V, Networking, Server 2008 R2 Leave a comment