Lync

NYC Lync User Group January Meeting: Mobility

I have decided to start up a User Group in New York for Lync! Our first meeting will be on Lync Mobility.

 

Check it out!

 

clip_image002[4] New York City User Group

 

About Us: The NYC Lync User Group is targeted at IT Pros and Developers interested in Microsoft Unified Communications. Our goal is to provide the NYC area with a vast amount of valuable information as it relates to all forms of Microsoft Unified Communications. Our meetings will include both Technical and Business information relating to Lync 2010, and other components of the Microsoft UC product suite.

The NYC Lync User Group will be conducting their first meeting January 19th, 2012! With the introduction of Microsoft Lync Mobile, businesses deploying Lync Mobility Features will need to understand the new architecture requirements, and the new features available to their users. This meeting will focus on Mobility in Lync Server 2010. Microsoft Most Valuable Professional Randy Wintle (Speaker Bio here) will present Lync Mobility including the following:

·         Lync Mobility Overview

·         Lync Mobility Platform and Features

·         Lync Mobility Architecture Overview

·         Important Lync Mobility Architecture Considerations for organizations

·         Live Demo (Windows Phone 7 and IOS)

Both Microsoft and Industry Lync Experts will be onsite to deliver this presentation, and help answer any questions related to Lync Server 2010.

For our first meeting, we will be raffling off an Xbox 360 Kinect Bundle in addition to other great Lync prizes!

Food and Drink will be provided free of charge by Plantronics.

Please see our website to register for this event and receive updates on all of our future events:

www.lyncusergroup.com

 

Like us on Facebook!

Date: January 19th, 2012

Time: 7PM EST

Location:
Microsoft NYC Office
1290 Avenue of the Americas, 6th Floor
New York, NY 10104
Phone: 212-245-2100

 

Brought to You By:

clip_image003[4]clip_image005[4]clip_image006[4]

 

See you there!

(49)

Posted on by Randy Wintle in Lync, Unified Communications Leave a comment

What happens when you’re A/V Edge Is Misconfigured: STUN/TURN

Ran into a very interesting issue recently at a customer. Below is the scenario:

 

OCS 2007 R2

Two pools, each with an associated edge pool.

POOL01

Associated Edge Pool : EDGEPOOL01

Audio/Video Edge Public Interface: AV1.CONTOSO.COM

POOL02

Associated Edge Pool: EDGEPOOL02

Audio/Video Edge Public Interface: AV2.CONTOSO.COM

First, the issue: External users homed on POOL02 cannot make/receive calls through the Edge.

We took Wireshark/Network Monitor traces from the external client when the client attempted to make an audio call. While reviewing traces of the call flow, the following error was thrown during the attempted allocate request(To see more details on the expected behavior of this process, check out the Lync Resource Kit Edge Chapter):

SNAGHTML31d4f38

The Username Supplied in the request is not known.

The user was sending an allocate request with all required information, Username, Nonce, Realm and Message-Integrity however the A/V Edge Service was rejecting the authentication request stating that the username was unknown.

Next, we reviewed the client UCCAPI log (located at %userprofile%tracingCommunicator-uccapi-0.uccapilog). When reviewing for the initial SIP INVITE from the user, the candidate list is incomplete. External users must also send Reflexive (Home router public IP Address) and Relay (A/V Edge Interface) IP and port combinations that have been allocated for media.

The initial thought was to attempt a connection to the A/V Edge Public Interface on 443. When users initiate calls they must be able to contact the server on 443 TCP and 3478 UDP to allocate ports. A quick telnet test proved that these connections were open. This proved the theory that the user could not allocate ports with the edge, although it could contact the edge on the proper ports.

m=audio 54614 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

k=base64:nhaKMJIOaPHKdhfepODlQie2p7zJaebDfnBYNMm9mBFOazb2tP9neS3ujKlU

a=ice-ufrag:c8rO

a=ice-pwd:jWSqHXAXIcvK1sC2nrkqCRin

a=candidate:1 1 UDP 2130706431 192.168.1.103 54614 typ host

a=candidate:1 2 UDP 2130705918 192.168.1.103 54604 typ host

a=candidate:4 1 TCP-ACT 1684798463 192.168.1.103 54614 typ srflx raddr 192.168.1.103 rport 54614

a=candidate:4 2 TCP-ACT 1684797950 192.168.1.103 54614 typ srflx raddr 192.168.1.103 rport 54614

a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:nMf0n5KQE7L+fajVqoWo+DCMzKj7lHLfwskTMOTt|2^31|1:1

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:XykNc+3nFqRWu3l5IJJs/cAFvsUqaL5/ZaVdRhoa|2^31|1:1

a=maxptime:200

a=rtcp:54604

 

The next step was to review the MRAS request during sign on to validate that it was actually receiving valid media relay credentials, and this is where the issue was spotted. To do this, we opened the client UCCAPI log and searched for MRAS(Detailed Information on this process, and tracking these processes can be found in the Lync Resource Kit Edge Chapter): In the MRAS request the client receives a valid 200 OK From the server, with what would be assumed are valid credentials and server information:

 

<?xml version=”1.0″?>

<response xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” requestID=”80980176″ version=”2.0″ serverVersion=”2.0″ to=”sip:EDGEPOOL02.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:k44hfHH-N0O1pJWhN9MnEwAA” from=”sip:USER@contoso.com” reasonPhrase=”OK” xmlns=”http://schemas.microsoft.com/2006/09/sip/mrasp”>

  <credentialsResponse credentialsRequestID=”80980176″>

    <credentials>

      <username>AgAAJN8hM4EBzG7J4jA/qyQcaH0fLODfJIKYVcqXB+AAAAAAJ9quG1tl843+fGcJJb7mI50sneg=</username>

      <password>NkWjWOauEzbKRaQrCNVyf6NXwHU=</password>

      <duration>480</duration>

    </credentials>

    <mediaRelayList>

      <mediaRelay>

        <location>internet</location>

        <hostName>AV.contoso.com</hostName>

        <udpPort>3478</udpPort>

        <tcpPort>443</tcpPort>

      </mediaRelay>

    </mediaRelayList>

  </credentialsResponse>

</response>

 

Because the user is associated with POOL02, it should have received AV2.CONTOSO.COM as its public A/V Edge for Media Relay. However, due to a misconfiguration on the edge pool, the MRAS service was handing back the POOL01 A/V Edge Service. Because of this, the user would connect to that edge pool, but when attempting to allocate ports, the edge server had no idea who that user was.

The fix for this issue was to validate the R2 Edge External Interface configuration, we found that AV.CONTOSO.COM was configured as the public DNS name for POOL02, when it should have been AV2. CONTOSO.COM. As soon as this was updated, the issue was resolved.

Below is a reference diagram to help understand the issue.

 

 

DeloitteMediaRelayIssue

(2116)

Posted on by Randy Wintle in Edge, Enterprise Voice, OCS 2007 R2, Unified Communications 1 Comment

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

(3019)

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

Lync RBAC with Child Domains Bug- Fixed in CU2

Prior to Lync Server CU2, if you attempted to create a custom Administrator Role to a child domain, with a user scope set to that child domain it would not work. Example Provided Below:

Contoso.com: Empty root domain

Site 1:Child1.contoso.com

1x Std Edition Front End w/ CMS

Site2: child2.contoso.com

1x Std Edition Front End

Lets say we wanted to create a custom admin role that gave an administrator in the CHILD2 domain to manage his users specifically in the CHILD2 domain. Assume In this scenario you would be logged into the CHILD1 domain with full admin permission on all domains, and CSAdministrator.

The cmdlet would look like this:

New-CSAdminRole –Idenetity Child2CSUserAdministrator –UserScopes “OU:ou=Users,dc=child2,dc=contoso,dc=com” –Template CSUserAdministrator

Before Applying CU2 you would receive the following error:

Set-CSAdminRole : Organization unity (OU) or container “ou=Users,dc=child2,dc=contoso,dc=com” does not exist. Specify a valid OU or container, and then try again.

Once you apply CU2 this error would go away and you would successfully be able to create the custom Admin Role.

Another similar issue with creating or modifying admin roles to have a use OU scope, is that they are Case Sensitive! The OU must be in the exact case as is seen in Active Directory. See the screenshot below for an example, in my lab, when trying to set an admin role with “users” instead of “Users” it fails, switching to “Users” succeeds.

clip_image002

Hope this helps!

(126)

Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, RBAC, Unified Communications 1 Comment

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.

(31)

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

(2894)

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

Using OCS 2007 R2 CWA with Lync Server 2010

At this time, there are going to be a few scenarios where you may need to deploy the R2 version of Communicator Web Access with Lync Server 2010. The core reason here, is that the RTM Version of Lync Server 2010 contains a feature on the front end called Lync Web App. Eventually, Lync Web App will become a full featured web client, however, today it is only used for users to join online meetings from the web. There is no ability to access Lync Web App from a URL and sign-in, or use it as a instant messaging too. This is planned to be released SP1 of the product, that timeframe is unknown right now.

To fill this gap, customers will have to deploy the OCS 2007 R2 CWA role, which can register against a Lync Server 2010 Pool. This post will show you how to configure OCS 2007 R2 CWA to work in your Lync Server 2010 environment.

 

Preparing the Environment

The most important piece of information in this blog, is that the Schema Prep for OCS 2007 R2 must be run in the environment before the Lync Server 2010 Schema Prep, or you will not be able to install the R2 version of CWA. If this is a deployment where there have not been prior installs of OCS 2007 R2, you will need to obtain this media, and run that Schema Prep before your Lync deployment starts, so it is very important to plan for this in your design/planning phase of your project.

Also, to get straight to the point for this blog, I am going to assume you have prepared the schema in the correct order, have your Lync Server 2010 environment online, and have already installed the CWA Role on a server. I will walk through creating the virtual directory, as well as integrating it with your Lync environment.

Use this Deployment Guide to install and configure the CWA role

Creating the OCS 2007 R2 Virtual Web Server

One you have the CWA role installed, and a valid certificate installed on the server, you must configure the virtual web server that clients will access.

I will walk you through the process for creating an External web server, however the same process applies for the Internal web server. The difference being the types of authentication allowed, external allows forms, where as internal also allows NTLM authentication.

Login to your R2 CWA server, and open the Communicator Web Access Admin Console

image 

Once in the admin console, right click on your server and choose Create Virtual Web Server

image

Navigate through the setup wizard, choose only your Web Server Type, in my case I am choosing External. Make sure to select a valid HTTPS certificate when prompted.

When you get to this section, Specify IP Address and Port it is important to note that this is the IP and listening port for your web server, not the communication between Lync and your CWA server, we will get to that next.

image

After entering a description for your virtual web server, the most important part of this wizard is the Specify a Listening Port section. This port defines what this application will listen on, and communicate with your Lync front end on. Because of the change in ports between OCS R2 and Lync, previously used values like 5070, or 5071 as you will see in older blog posts of mine do not work. You must pick a port that is not being used by an application currently. For my example I am using 4790.This can be any port, as long as your Lync front end and this server can communicate on that port.

image

Next, define your next hop pool, choose the appropriate Lync pool as your next hop and leave the port to default 5061.

image

Complete the wizard and start the virtual server.

Your settings should look similar to this

image

Now that you have completed this, you will need to make Lync aware of this server.

As you will find in the OCS 2007 R2 to Lync Server 2010 Migration Guide, you must merge your Legacy (OCS 2007 R2 components in to your Lync Topology.

Configuring Lync Server 2010

Now that we have our CWA server configured, we must make the Lync topology aware of this server. To do so, we will merge the legacy topology in to our Lync topology. This is possible through PowerShell using the Merge-CSLegacyTopology cmdlet, however I will be using the GUI.

Before completing this task, you must install the OCS WMI Backwards Compatibility tool, this can be found on the install media, called ocswmibc.msi

First, navigate to your Lync front end and open the Topology Builder.

If you already have coexistence with a R2 environment you will be very familiar with this process, and you will also see the BackCompatSite listed.

image

Right click where it says Lync Server 2010 and choose Merge 2007 or 2007 R2 Topology

image

In this post, I am assuming there are no R2 pools, and we are just importing the CWA server and web site. Because of that, you will actually leave the wizard blank when it asks for servers. This wizard will connect to servers in your environment and pull configuration data out of WMI, and input them into this BackCompatSite that will reside on the CMS. This is the major change from OCS 2007 R2 to Lync, is what used to be in WMI, is now in the CMS. You can find plenty of resources to get into more detail about that on Nexthop.

image

image

image

Verify the setting selected in the wizard, and choose Next to merge your legacy topology.

Everything should complete, choose Finish and you will now see your new site.

image

Expand BackCompatSite and expand TrustedApplicationServers for this blog post, we are concerned only with the trusted application servers, this is where your CWA, and other R2 server roles like group chat will appear.

image

Once you have verified that your R2 CWA server appears correctly, right click where it says Lync Server 2010 and choose Publish Topology.

image

 

Once you have published your topology, we will have one last step to verify our web server was imported correctly.

Open the Lync Server Management Shell and run the following command: Get-CSTrustedApplication

This command will return trusted applications that are associated with Trusted Application Servers and Trusted Application Pools in your environment, you may have many depending on your topology. However the two we are looking for, involve CWA.

Your output should return something similar to below:

image

I have crossed out my server names, however there should be the FQDN of your CWA server where I have marked.

The two entries represent the external facing web site that users hit, as well as the port that is used to communicate with the Lync front end, as you can see highlighted below, the port you assigned should be listed there.

image

You should now be able to login to CWA as a Lync Server 2010 user! If you run into issues, make sure to check out this blog relating to the SPN error related to CWA service accounts in R2.

http://theucguy.wordpress.com/2009/03/27/communcator-web-access-r2-error-0-1-492/

Also, make sure that your CWA server is on the latest release of OCS 2007 R2 patches which can be found here:

http://technet.microsoft.com/en-us/office/ocs/ee695846.aspx

 

I hope this helps you extend CWA capability to your Lync users, if you have any issues please contact me via the comments and I will try to help you the best I can.

(784)

Posted on by Randy Wintle in CWA, Lync, Lync RC, Microsoft, OCS, OCS 2007 R2, Reach Client, Unified Communications 39 Comments

Error When Installing UM Role on Exchange 2010 SP1

11/12/2010 12:31:24.0997] [2] Active Directory session settings for ‘install-umservice’ are: View Entire Forest: ‘True’, Configuration Domain Controller: domaincontrollerfqdn, Preferred Global Catalog: “domaincontrollerfqdn”, Preferred Domain Controllers: ‘{ domaincontrollerfqdn }’
[11/12/2010 12:31:24.0997] [2] Beginning processing install-UMService
[11/12/2010 12:31:26.0012] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:26.0012] [2] [ERROR] There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] The following 1 error(s) occurred during task execution:
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
   at Interop.NetFw.INetFwRules.Add(NetFwRule rule)
   at Microsoft.Exchange.Security.WindowsFirewall.ExchangeFirewallRule.Add()
   at Microsoft.Exchange.Configuration.Tasks.ManageService.Install()
   at Microsoft.Exchange.Management.Tasks.UM.InstallUMService.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()

 

When running the wizard to add the UM role to your Exchange 2010 Sp1 server, you may have this error appear in the install wizard:

ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

If you take a look at the Exchange setup log, it is trying to add firewall rules, and fails, and kills the install. If your windows firewall service is not running, you must start it.  Re run the installation with windows firewall running, and all is fine Smile

(129)

Posted on by Randy Wintle in Enterprise Voice, Exchange 2010, Exchange UM, Lync, Microsoft, OCS 2007 R2, Server 2008 R2, Unified Communications 5 Comments

Lync Server 2010 Active Directory References, and how to Remove Them

A common theme I am seeing lately is that people have setup Lync test environments, and are required to start from scratch for one reason or another. The problem is active directory is still detecting their old topology and causing issues with moving forward with the new environment.This post will cover what is required to remove references to the Lync deployment from Active Directory.

One very important thing to note here, once you extend your AD Schema, unless you revert from a backup, you will not be able to back out those changes. As a quick reference, lets go over what Lync Server 2010 does when you extend the schema.

In Office Communications Server 2007 R2, majority of configuration data was stored in Active Directory, however Lync Server 2010 stores most of the configuration data in the Central Management Store, which is a SQL database that lives on your servers in the topology. Lync Server 2010 still stores certain information in active directory including:

  • Schema extensions:
    • User object extensions
    • Extensions for Office Communications Server 2007 and Office Communications Server 2007 R2 classes to maintain backwards compatibility with supported previous versions
  • Data (stored in Lync Server extended schema and in existing schema classes):
    • User SIP Uniform Resource Identifier (URI) and other user settings
    • Contact objects for applications such as Response Group and Conferencing Attendant
    • A pointer to the Central Management store
    • Kerberos Authentication Account (an optional computer object)

Now, there are a ton of Attributes and Classes involved, because of the backwards compatibility with OCS 2007 R2, however I am simply going to cover the references to your pools, pool servers and your topology, and how to get rid of them. When the RTM documentation is released, it will have a full list of all attributes and classes.

Central Management Store References

The key change in Lync Server 2010 is the reference to the Central Management Store that is created in active directory. When you install your first server in the environment an Active Directory Service Connection Point is created in AD referencing the location of the central management store, all servers going forward pull from that reference point to identify where they should be pulling configuration data from. Once they have made that first pull, Lync Server 2010 keeps each of the local configuration stores up to date in a replication process. It’s a similar setup to Active Directory, if you think about domain controllers having a local store of data, and it replicates across all, same concept with the Lync CMS.

You can view this SCP through ADSI Edit.

Open ADSI Edit and connect to the context where your data is stored, either Configuration or System. Below I am showing System.

Expand Microsoft->RTC Service->Topology Settings

image

If your right click and choose Properties you will see the most important data, the server and version that is holding the CMS.

propertiesofcms

Essentially the commands below manage this entry.

There are a couple PowerShell commands that can be used to manage the CMS Connection in Active Directory.

Commands to view the status and location of the CMS

 

The command Get-CSManagementStoreReplicationStatus

This command can be run by itself to see the status of replication across all of the servers in your topology

Get-csmanagementstorereplicationstatus

You can also run this command with the switch –CentralManagementStoreStatus to view information about your central management store:

csmanagementstorestatus

This command will give you very valuable information, for this purpose it will show you what your connection point is referencing, and in troubleshooting, you will be able to identify any issues with your CMS.

You can also do a very basic command to report on the location of the CMS.

The command Get-CSConfigurationStoreLocation

This simple command will print the CMS location in a single line.

There are a couple ways we can change where the CMS reference in AD points to, as well as to completely remove the connection point.

Modifying or Deleting the CMS Location in Active Directory

 

The command Move-CSManagementServer

This command will move your CMS between pools. This is useful if you have your existing CMS still online, and will be making a smooth transition to the new servers. If you do not have your old CMS server available, you will not be able to use this command unless you have a valid backup of your configuration data. These backups can be obtained by running Export-CSConfiguration and Export-CSLISConfiguration. That will backup to ZIP files, which can then be used with the Move-CSManagement store command to restore the configuration and repoint the SCP to the new pool.

The syntax for this command is pretty basic, here is the reference from the Help File:

Before you move the Central Management Server, you must do the following:

1. Verify that you have created the new Central Management store. This is d
one by running the Install-CsDatabase cmdlet and using the CentralManagemen
tDatabase parameter.

2. If you are moving the Central Management Server to a Standard Edition se
rver, verify that you have used local setup to run the Prepare Standard Edi
tion server option. This advance preparation is required to add firewall ru
les that will allow Windows PowerShell to remotely access the new Central M
anagement store.

3. Verify that there is enough free disk space on the computer where Move-C
sManagementStore is being run to accommodate the Central Management Server.

4. Verify that the Front End Server service has been installed on the compu
ter where Move-CsManagementStore is being run. If this service is not insta
lled, and running, then the move will fail.

5. Verify that you can successfully run the Enable-CsTopology cmdlet on the
computer where Move-CsManagementStore is going to be run. If Enable-CsTopo
logy cannot be run on that computer then the move will fail and you will no
longer have a functioning Central Management store.

After you have completed these steps, all you need to do to move the Centra
l Management Server from Pool A to Pool B is log on to a computer in Pool B
and then call Move-CsManagementServer without any additional parameters:

Move-CsManagementServer

When you do that, Move-CsManagementServer will consult the topology to dete
rmine the prior location of the Central Management Server  (Pool A), and th
en transfer the Central Management Server and the Central Management store
to the current pool (Pool B).

If the move succeeds, Move-CsManagementServer will display a list of comput
ers on the screen. In order to finish the move, you must run local setup on
each of these computers. Computers in Pool A will still be running an inac
tive version of the Central Management service; running local setup will de
lete that service. The computer in Pool B where the Central Management Serv
er was moved will be running the Central Management service; however, other
computers in the pool will not. Running local setup on these computers wil
l install the Central Management service.

 

 

Two important parts:

  1. Make sure you have properly prepared your new Front End/Pool Server prior to running this command (see documentation on setting that up)
  2. Login to the NEW server which will contain the CMS, open the Lync Powershell, and run Move-CSManagementServer

    The command Remove-CSConfigurationStoreLocation

    This command will actually remove the service control point in Active Directory that points to your Central Management Store. You can also include the parameter –Report with a file path to output a report of the activity for confirmation.

    When you perform Remove-CSconfigurationStoreLocation the reference is deleted from active directory.

    This step would be more common in lab scenarios where you are starting from scratch and just need a quick and dirty way to remove reference to your topology. To completely remove references to old topology objects, you will also need to remove some additional entries using ADSI Edit.

    How to Remove Server Entries from AD using ADSI Edit

    When you deploy a Lync topology in your environment, the servers are also references in AD. Most importantly, when you do not properly remove a server, there will be stale references to this throughout the entire RTC Service CN in Active Directory.

    I will show you how to remove references to these old servers and old pools.
    When you are looking at the tree, you will find specific references to servers and pools in Global Settings, Pools, Trusted MCUs, Trusted Services and Trusted WebComponentsServers.

You may also find old references to application contacts and conference directories if those were not properly removed. It is safe to say that you can run through each of these and remove references to your old servers if you are certain they will not be in use anymore.

Global Settings and Trusted Services

If you expand Global Settings you will see entries, the number of entries will depend on how much you have going on in your environment.

image

We can search for specific servers are are looking to remove by using LDP to perform queries looking for this server.

First, you must open LDP and bind to the correct DN.

Start->Run type LDP and hit enter

image

Select Connection choose Connect and enter a valid domain controller to connect to

image

Then you must Bind as a valid user, choose Connection and choose Bind, either use the currently logged in user, or specify an account with privileges.

image

Now we will display the Tree we will be searching through. Select View->Tree

image

If your information is stored in your System container, you must choose DC=domain,DC=com where domain is your domain. If it is stored in configuration you should choose CN=Configuration,DC=Domain,DC=COM

image

Expand down to your RTC Service container that we were viewing before in ADSI Edit

image

Now that we are bound and connected to the correct tree, its time to start searching. If your server is referenced in Global Settings or Trusted Services we will be looking for msRTCSIP-TrustedServerFQDN

Right Click on RTC Service and choose Search

image

For the filter enter the following, replacing serverfqdn with the server you wish to remove

(msRTCSIP-TrustedServerFQDN=SERVERFQDN)

In my example I am searching for “winx-cs2010b3.winxnet.com”

image

Make sure to select Subtree so it searches all trees below for this entry.

Select Run, the query should return results in the right pane with specific CNs, we will want to navigate to these Cs and delete them.

image

Copy these results, we will use them as a reference to delete these entries using ADSI edit.

Before deleting, review the properties of each of the CN to make sure it is a valid item to delete. Most of these are references to the individual services on those machines, which is evident from the different TrustedServicePort and ServiceType

image

Open ADSI Edit for each entry in your search results, navigate to the full DN, right click and choose Delete

image

Pools

Pools usually does not require the use of LDP as the list is so short and easy to identify. Lync identifies pools in active directory with numbers, if you have any beta pools, you may also see them referenced as Sitename:1,2,3 . As you can see in my screenshot, I have a few of each. identify the pool you want to delete, and simply right click and choose Delete

image

Trusted MCUs

The Trusted MCUs entry is similar to Trusted Services. We will perform a LDP query for the attribute msRTCSIP-TrustedMCUFQDN

Follow the steps above for Global Settings and Trusted Services replacing msRTCSIP-TrustedServerFQDN with msRTCSIP-TrustedMCUFQDN

image

Your results should return three per server, because of IM/Audio/Video and Data. Copy the results and set aside.

Following the same steps above for Global Settings and Trusted Services, delete each DN that you wish to remove.

image

Trusted WebComponentsServers

Trusted WebComponentsServers entries are created usually per front end server you put in your environment both for OCS 2007 R2 and Lync Server 2010. You can search using LDP and the attribute msRTCSIP-TrustedWebComponentsServerFQDN

Follow the same steps above to search for that attribute, and delete any DNs associated with the server you are trying to remove.

I hope this helps people understand how the central management store is referenced in active directory, and also how to do some cleanup if you did not properly remove servers from your environment. As always. open to comments about ways to improve the methods, or your own methods for performing these steps!

(6975)

Posted on by Randy Wintle in Communications Server 2010, Lync, Lync RC, OCS, OCS 2007 R2, Unified Communications 31 Comments

Powershell Script to create new user, enable for Exchange, UM and Lync Server

I created this powershell for our internal onboarding process, figured I would share it with the masses.

I think there are a couple good takeways from this script, it remotes into Exchange 2010 and Lync Server 2010 Powershell sessions, so nothing except Powershell 2.0 is required on the client side, which is standard with Windows 7. It also shows how you can simultaneously use Exchange and Lync powershell commands in the same script to get things done.

A couple of disclaimers:

I am in no way advanced at powershell scripting, so nothing fancy here.

This was developed specifically for my internal needs, you will probably have to add/remove variables and requirements.

http://cid-389bd51b03b1f8f9.office.live.com/embedicon.aspx/Public/UserSetupScriptGeneric.ps1

 

Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.

(685)

Posted on by Randy Wintle in Enterprise Voice, Exchange 2007, Exchange 2010, Exchange UM, Lync, Lync RC, Microsoft, OCS, OCS 2007 R2, Unified Communications 12 Comments