Category Archives: OCS
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
Once in the admin console, right click on your server and choose Create Virtual Web Server
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.
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.
Next, define your next hop pool, choose the appropriate Lync pool as your next hop and leave the port to default 5061.
Complete the wizard and start the virtual server.
Your settings should look similar to this
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.
Right click where it says Lync Server 2010 and choose Merge 2007 or 2007 R2 Topology
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.
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.
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.
Once you have verified that your R2 CWA server appears correctly, right click where it says Lync Server 2010 and choose Publish Topology.
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:
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.
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.
Also, make sure that your CWA server is on the latest release of OCS 2007 R2 patches which can be found here:
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.
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
If your right click and choose Properties you will see the most important data, the server and version that is holding the CMS.
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
You can also run this command with the switch –CentralManagementStoreStatus to view information about your central management store:
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
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
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:
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:
- Make sure you have properly prepared your new Front End/Pool Server prior to running this command (see documentation on setting that up)
- 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.
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
Select Connection choose Connect and enter a valid domain controller to connect to
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.
Now we will display the Tree we will be searching through. Select View->Tree
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
Expand down to your RTC Service container that we were viewing before in ADSI Edit
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
For the filter enter the following, replacing serverfqdn with the server you wish to remove
In my example I am searching for “winx-cs2010b3.winxnet.com”
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.
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
Open ADSI Edit for each entry in your search results, navigate to the full DN, right click and choose Delete
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
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
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.
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!
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.
Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.
I am very proud to announce that I have been awarded 2010 Microsoft MVP for Communications Server!
Here is a quote from the MVP site on what this means exactly:
The Microsoft MVP Award recognizes exceptional technical community leaders from around the world who voluntarily share their high quality, real world expertise with others. Microsoft MVPs are a highly select group of experts representing technology’s best and brightest who share a deep commitment to community and a willingness to help others. Worldwide, there are over 100 million participants in technical communities; of these participants, there are fewer than 4,000 active Microsoft MVPs.
At Microsoft, we believe that technical communities enhance people’s lives and the industry’s success by providing users with the opportunity to have conversations about technology that catalyze change and innovation. Technical communities help users adopt new technologies more quickly and more effectively. Also, they help Microsoft product developers understand the "pulse" of our users and better meet our customers’ needs. As the most active, expert participants in technical communities, MVPs are recognized and awarded for their inspirational commitment to technical communities.
In order to receive the Microsoft MVP Award, MVP nominees undergo a rigorous review process. Technical community members, current MVPs, and Microsoft personnel may nominate candidates. A panel that includes MVP team members and product group teams evaluate each nominee’s technical expertise and voluntary community contributions for the past year. The panel considers the quality, quantity, and level of impact of the MVP nominee’s contributions. Active MVPs receive the same level of scrutiny as other candidates each year.
MVP Award recipients reflect Microsoft’s global customer base and the breadth of Microsoft’s technologies. MVPs have been awarded in new categories such as Windows Live, Xbox, VSTO, Microsoft Dynamics, and Visual Developer Team System. A significant portion of new MVPs represent emerging markets in China, Russia, and Korea, as well as smaller markets like Ghana, Nepal, Macedonia, and Macao.
MVPs also represent the diversity of today’s technical communities. Respecting the user’s desire to get technical information in a variety of ways, Microsoft recognizes both online and offline community contributions. Reviewers consider the contributions that nominees make to traditional communities such as public newsgroups and third-party Web sites, as well as emerging community venues such as forums and blogs.
Microsoft MVPs are an amazing group of individuals. By sharing their knowledge and experiences and providing objective feedback, MVPs help people solve problems and discover new capabilities. It gives us great pleasure to recognize and award MVPs as our way of saying thank you for their demonstrated commitment to helping others in technical communities worldwide. We sincerely appreciate their efforts. Microsoft would like to congratulate and thank this year’s MVPs.
Thanks to everyone who views my blog, and finds this information useful. More great content to come this year!
An update has been released for COMO. If you are one of the lucky people out there running windows mobile, update now.
Issues that this hotfix package fixes
- Provides home screen support for new home screens in Windows Mobile 6.5+ phones.
- Provides integration within the phone dialer for Windows Mobile 6.5+ phones.
- Enables Communicator Mobile 2007 R2 to recognize when the phone is roaming and by default prevents Communicator Mobile 2007 R2 from signing in to roaming networks.
- Provides additional support for joining conference calls from a Windows Mobile appointment. To do this, press Menu, and then press Join Conference.
- Lets users log on by using a user name in the firstname.lastname@example.org format, in addition to the domain\user format.
- Enables the functionality by which callbacks are now automatically accepted when the user uses the Call via Work option.
- Resolves the problem in which the Microsoft Installer (.msi) installation fails on a Windows XP Service Pack 3 (SP3)-based computer. In this situation, users should install Communicator Mobile 2007 R2 by using a (.cab) installation.
- Fixes the problem in which AT&T FUZE devices that are set for a High-Speed Downlink Packet Access (HSDPA) connection cannot handle voice and data at the same time. In this situation, calls that use the Call via Work option fail unless the device is reverted to 3rd Generation (3G) by disabling HSDPA.
In my previous post I outlined configuring Forefront TMG 2010 to publish the OCS 2007 R2 web components. Please see that post for basic installation instructions and network configurations.
In this post, I will outline publishing Communicator Web Access (CWA) to the internet using Forefront TMG 2010.
DNS Records and Certificate Requirements
First lets cover the new DNS records and certificate entries required for communicator web access. With the addition of desktop sharing to CWA, additional DNS records and certificate entries are required to provide that functionality.
The following DNS records are required for CWA:
CWA Desktop Sharing
CNAME to cwa.domain.com
CWA Desktop Sharing
CNAME to cwa.domain.com
Your certificate will need to have all of the names above on it.
In my environment I have the following certificate information:
Common Name: cwa.winxnet.com
Subject Alt Name(s): as.cwa.winxnet.com download.cwa.winxnet.com
CWA Web Site Configuration
In my example I have two web sites configured on the CWA server. One for internal access and one for external access. When you create virtual servers for CWA you have two options for site types, Internal and External. The only difference is authentication type. Internal sites will let you choose NTLM authentication, which allows for simple access from inside the corporate network on domain joined machines. External sites will use Forms-Based Authentication, or Custom Authentication. Custom authentication can be used to perform two factor authentication with services like RSA or other smart card/pin authentication methods.
In our example our Internal site will be a standard internal site listening on port 443. Our external site however will run on port 4443, and we will perform bridging with the forefront TMG server to give users access to this site.
I will outline creating the external web server, assuming an internal web server has been configured listening on port 443.
First, open the Communicator Web Access management console, this is separate from the OCS 2007 R2 primary admin console, but is included when you install the admin tools on any machine.
Right click on the server name and choose Create Virtual Web Server.
At the next window, this is where you will choose your web server type, choose External.
The next window allows you to choose your authentication types. If you were using a third party authentication method you would specify it here. Although it says in the description that the built in windows integrated and forms-based authentication will be used, the external web site will only allow Forms-Based Authentication.
The next window confirms those authentication settings, notice NTML is grayed out.
The next screen has you specify an SSL certificate to be used with the https requests. You can choose HTTP if you are using an SSL Accelerator device, but you cannot use CWA over HTTP without such a device.
Choose the certificate you created with all the necessary name entries and hit Next
The next screen has you specify the IP address and port the web site will listen on. If you have an additional IP address you can use port 443 with a separate IP than your internal server. In our example, I will be using a single IP address and utilizing bridging with Forefront TMG, so I will enter the port as 4443.
On the next screen, enter a name to identify the external web site such as CWA External.
The next screen has you specify a port to listen to OCS traffic. This is seperate from the web site listening settings. This port is really important if you are collocating OCS Services, or even in this case where we have multiple CWA virtual servers on the same server. This port really does not matter, as long as it does not conflict with another port on the same server used for OCS Traffic. In my case I am entering 5071, my internal server listens on 5070.
At the next screen you must specify a Next Hop Pool, this drop down will display all the pools in your environment and allow you to choose a pool and listening port. In my case our poolname is ocs.winxnet.com.
Hit Next twice to confirm your settings for the new virtual server, the wizard will create the virtual directory and start the web site for you. As with all of the OCS installations, a log is available at the end for success and failure.
Now review your two sites, a screenshot of how the site summary should display is below.
Now that the OCS configuration is complete, we will configure Forefront TMG Web Site Publishing rules to allow traffic to your CWA services.
Forefront TMG 2010 Configuration
My last post reviewed networking configurations for this Forefront server. You can get away with a single External/DMZ IP address for all of these services if you have a single certificate with all of the names. In my case I have multiple certificates, so another IP address will need to be assigned to the DMZ network card on my Forefront TMG 2010 server.
Once you have added your external IP address, and imported the certificate used on your web server; (See my last post for instructions on both of these steps). We will now create the web site publishing rule for CWA.
Right click on Firewall Policy and choose New->Web Site Publishing Rule.
For a rule action, choose Allow. Hit Next
For the Publishing Type choose Publish a single web site or load balancer. Hit Next.
For Server Connection Security choose Use SSL to connect to the published Web server or server farm. Hit next.
For your internal site name, you will want to specify the same Internal/External site name, whatever is the common name on your certificate, in my case it is cwa.winxnet.com.
If you cannot resolve the name correctly from the TMG server, or want to specify a different computer to connect to for that name, you can do so by specifying a computer name or IP Address.
Once you have made the necessary entries, hit Next.
For internal publishing details, under path type /* to allow all sub directories required by CWA. Hit Next.
Under Public Name Details enter the public name for your site, and hit Next. In my case it is cwa.winxnet.com.
On the next page to specify a web listener, choose New.
In the new web listener wizard first page, enter a name for the listener like CWA.
For Client Connection Security choose Require SSL secured connections with clients.
On the Web Listener IP Address page, select the check box next to External, highlight external and choose Select IP Addresses… On this next page, specify the IP address you set aside for CWA.
Hit Next, on the next page for Listener SSL Certificates, highlight the IP Address selected on the last page and choose Select Certificate… Choose your valid certificate and choose Select. Hit Next.
For Authentication settings, choose No Authentication.
Because we chose No Authentication, we have no SSO options, just choose Next.
Review the settings for your listener and hit Finish.
With your listener selected from the drop down menu, hit Next.
For Authentication Delegation choose No Delegation, but client may authenticate directly. Hit Next.
Leave the default settings for User Sets and hit Next.
On the next page, select Test Rule to verify all rule settings are correct. If the result is OK, hit close, then select Finish.
Make sure to Apply your settings to the Forefront TMG server before continuing.
If you had a separate IP address for you internal site, and your external site you do not need to do the next step. This next step will configure bridging to direct our user request to port 4443 for this external virtual server.
Right click on your CWA rule and choose Properties.
On the Properties page, select the Bridging tab.
Where it says Redirect requests to SSL port, enter port 4443, or whatever port you specified during your website configuration. Hit OK.
Again, apply your changes before continuing.
You can test the rule again from the Properties page. Simply open the Properties page for the rule and Test Rule will be an option there. If the test returns OK, continue to test your site from a computer outside the network.
Testing and Known Issues
You can test access to this site from Internet Explorer outside the network, you should simply be able to specify the https:// URL of your site, and TMG 2010 will handle bridging the request to the correct virtual server on the CWA server. You can also use CWA for access to a great IPhone OCS App called iDialog by Modality Systems.
A very common known issue for CWA configurations is receiving the error Cannot sign in because your computer clock is not set correctly or your account is invalid. (Error Code: 0-1-492)
This is an easy fix, and has to do with Service Principal Name (SPN) settings for the CWA Site.
To fix this issue, simply add the correct SPN to your CWA Service Account. This is the account specified during CWA installation to run the service.
You can modify this setting using ADSI Edit, and looking for the attribute servicePrincipalName.
Other than those two instances, this configuration is pretty straight forward and just works.
I do not have any details on the exact cause of the issue at this point, but I recently did an OCS 2007 R2 deployment on Server 2008 R2. We followed the general instructions located on TechNet to install the OCS services on 2008 R2, but ran into an issue when performing user moves from LCS to OCS.
Not a lot of information in the errors, but pointed to a connectivity issue between the LCS server and the new OCS server.
The fix for this issue is to install the admin tools on a 2003 Server, once the admin tools were installed on a 2003 sever in the environment, the moves were successful. I am working on finding the exact cause, but I am betting it is related to the bullet item for admin tool compatibility issues listed on the 2008 R2 support page. Will update when I have more information.
During a recent group chat server installation, the wizard failed with a very cryptic error message after specifying the Lookup Service account. We also got the same message for the Channel Account configuration.
The error message looked like this:
A Google search turned up nothing, and a quick query on the formicary hosted UC Community Group Chat Channel didn’t have any immediate answers. Bryan Childs was able to point me in the right direction looking for the log on as service permissions on the box.
The customer in question had PCI requirements where service accounts are denied the right to logon interactively, if not they had to change the passwords on those accounts during their regular intervals for user accounts. This setting was the culprit. Once removing the policy denying the service account interactive login rights we were able to proceed with installation. I did notice that during the installation it grants those accounts the log on as service rights on the local box, not sure how related these settings are.
Anyways, seems the group chat errors are pretty generic, this may not even be strictly for this issue, however wanted to get the information out there.
Often I run into customers that want Remote Call Control with their current phone system as an integration architecture with OCS 2007 R2. Personally I see the benefit to remote call control in LCS, and OCS 2007 R1, but not with the R2 release, and especially with Wave 14 so close. Many times I have had to explain the different scenarios, and why I think a different architecture is a better way to approach this. Today I had to develop this information for a Cisco Call Manager implementation, and wanted to have a reference point, as well as share my thoughts on the subject.
To give a brief background, the customer wanted RCC with Cisco, they currently have an OCS infrastructure in place, and wanted to add the RCC functionality to that environment. In order to do this, they would need to upgrade to Call Manager 7, which is the very first reason to not go any further with the RCC architecture in my opinion. If you are investing in the Microsoft Unified Communications technology stack, there is no reason to dump more money into another UC product along side it.
As a summary, here is a description of what RCC is… Credit goes to this blog post http://blogs.technet.com/jkunert/archive/2008/07/30/voice-scenarios-with-ocs-2007.aspx
This is a description from the R1 release of OCS 2007 but still holds true today.
Remote Call Control (RCC)
Also this voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. The users OC client does not act as a soft phone, does not need an audio or audio/video device connected to the PC and the user is not able to make or receive phone calls by using her/his PC. This is not a VoIP scenario!
In this scenario, an OCS 2007 user has a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. In addition to that, Office Communicator (OC) 2007 is installed on the user’s PC.
In the office
On an incoming call the user’s PBX phone rings as well as that she/he receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of the PBX/IP PBX phone or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will stay on the PBX/IP PBX and there will be no VoIP connection to OC! The user does not need an audio device for telephony connected to her/his PC.
At home/on the internet
If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home), the users PBX/IP PBX phone will ring in the office (what she/he most likely will not be able to hear J) as well as that she/he can see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window will result in this scenario that the phone in the office will activate the speaker phone, but the user is not able to use her/his PC to talk to the caller. No VoIP connection through the internet is established! (However, the user can redirect an incoming call to her/his mobile phone and can pick up the call this way while working remotely.)
How it works in a nutshell
A CSTA Gateway (GW) needs to be installed between OCS 2007 and the PBX/IP PBX. Some PBX/IP PBX systems come with a CSTA interface natively so there is no need for an additional GW. Between OCS and the PBX/IP PBX call control commands will be sent, packed into a SIP INFO message that uses a long-lasting SIP dialog between OCS and the CSTA GW. The CSTA GW converts these call control messages into a format that the PBX/IP PBX understands. A CSTA GW is not a media GW so voice cannot be converted by a CSTA GW from a TDM (Time Division Multiplexing) or PSTN protocol to VoIP! OC can only control the functions of the PBX/IP PBX phone.
With a Cisco integration, we would actually be able to do direct sip as long as the following software requirements are met on the Cisco side:
- Cisco Unified Communications Manager Release 7.0(2)
- Cisco Unified Presence Release 7.0(3) with E.164 patch for RCC
One of the key features of the Microsoft OCS Platform is the ability to have not only integrated IM and Voice calling, but also conferencing, all within the same application, and all available through a single click. Any communication can be escalated to a conference by inviting PSTN or VOIP participants at any time. When you introduce the remote call control scenario this is no longer available. A Key thing to point out is that a user in this scenario cannot make or receive calls using communicator, they still must use the Cisco phone in all scenarios, which virtually eliminates the remote worker benefits of OCS. Below is the list of other limitations taken from the Cisco Documentation on this configuration:
Features Not Supported
· Microsoft OC logon from two locations
· Call Forwarding
· Location Based
· Phone Settings
· Conferencing through remote call control
· Conferencing: OCS 2007 R2 does not support call conferencing through remote call control. Conferencing is available in IP Phone
only or OC only call scenarios.
· Call forward setting on IP phone: Call forward setting made on the Cisco IP phone (desktop), using its soft key button or the Cisco
UCM phone configuration page, is not reflected by the Microsoft OC GUI. As of Microsoft OCS 2007 release, this feature is not
supported. The Microsoft OC can override any call forward setting manually configured on the IP Phone and vice versa.
· Call Forward Setting from OC: Call forward setting from the OC through remote call control (RCC) fails on the IP Phone when the IP
Phone is initially configured with an E.164 DN. If the IP Phone is reconfigured to a non-E.164 DN then back to the E.164 DN, the
call forward setting from OC through RCC will work. This is a known issue on Cisco UCM 7.0(2) and has been documented in
CDETS CSCsy62620 to be fixed in a future release.
· Do Not Disturb (DND): DND is an unsupported feature with respect to CUP integration. Thus, any OC client with DND feature
enabled, will still have any received calls routed to its controlled IP Phone.
· Multiple Point of Presence (MPOP): As of the CUP release 6.0(1), the MPOP feature where a Microsoft OC user is logged in from
more than one location is not supported by CUP. Support for this feature affects other interoperability features between the Cisco
CUP and the Microsoft OCS. The affected features include basic placement and teardown of calls and locations-based call forwarding.
These features are inherent to MPOP and without support for this feature, the user experiences loss of device and call control when
logged in multiple locations.
· Transport Layer Security (TLS) connection between CUP and OCS: this feature was not tested in this release.
As you can see, you quickly start to lose a lot of the functionality of OCS. I will stress that the above is strictly related to Cisco, and may not be completely accurate for other RCC Scenarios.
The other option, and most optimal solution in my opinion can be most closely referred to as a standard Enterprise Voice Scenario. Really, it is the cheap way of doing remote call control.
Last year I had multiple voice deployments which had to provide interop between OCS and the existing PBX, mostly Avaya and Cisco systems. A key requirement of all of these deployments was the ability to pilot OCS functionality but also have access to their old phone for use. The architecture we used to provide this can be seen below. We had to make a connection between the OCS environment and the PBX, whether it was a Sip trunk to cisco, or a PRI connection via media gateway to the other systems. From there we have two options for routing incoming/outbound calls for OCS enabled users.
The first scenario is where the PBX controls the call routing. All PRIs, or SIP trunks come directly into the PBX, from there you have routing rules to route certain numbers over a trunk to OCS. This can be accomplished by setting routing rules at the PBX level, or simply forwarding your PBX Desk phone to your OCS extension, which will route it over to the OCS Trunk. It is important to note that in both scenarios you are configured for different extension on the PBX and OCS. Where your “real” extension goes depends on how you wish to route/forward calls. Regardless, any DID numbers, or existing extensions are still usable, it’s just a matter of getting the call there. In this scenario for example, you may have “fake extension” in OCS, and when your existing extension is rung, your cisco phone forwards the call to your OCS extension, in the PBX this new block of OCS extensions is configured explicitly to route over that new trunk, this is the simplest way to make this connection happen with the least amount of changes on the existing PBX environment.
The other scenario lets OCS control the call routing. In this scenario all PSTN calls destined for OCS Enabled users go directly to OCS. This can be more difficult to implement at first, but once it is in place, it provides a very smooth transition. This can be accomplished from a direct SIP trunking connection to an OCS mediation server, or a PRI/POTS connection from a provider, into a media gateway, which then sends the calls on to the OCS mediation server. It is possible to move all incoming PRI connections to a media gateway, which would then control all calls. From there that media gateway can send to the PBX or OCS. In the Cisco world, this could actually be a 2800 or 3800 series ISR. To some people this is a bit scary to hear at first, but really, your current PRI lines come into some sort of gateway device as it is, this would provide the same functionality. The gateways used are by companies like Dialogic and NET with great experience doing this for years for traditional PBX systems, so it is more than reliable. From here, there is also a trunk setup to the PBX to route extension dialing, as well as for simultaneously ringing the legacy PBX phone. In both scenarios the voicemail can be sent to exchange unified messaging or back to the PBX voicemail system. When OCS has no answer, it can make this choice. The PBX will be smart enough when the call comes back and is tagged with no answer, to send it directly to voicemail instead of creating an endless ringing loop.
In scenario two, if the media gateway takes all PSTN calls in, it will have some basic routes on it. Routes that control sending OCS enabled users to the mediation server, and then a default route which will send everything to cisco. Basically, if you had 5 users enabled for OCS. You would have a rule on the gateway that had 1000-1005 with a destination of the mediation server. The second route would be * (any) with a destination of the PBX. This takes the load of modifying PBX configuration.
In this specific scenario, the media gateway could be a dialogic/NET device, or simply the PRI interface on the Cisco ISR.
It is important to note that with both of these scenarios you have full functionality of both systems at any given time. You can use your cisco phone to make and receive calls, or your OC client to make and receive calls. You can also take advantage of all conferencing, and other advanced functionality that OCS has to offer like remote access.
There may be some things that need clearing up in this, and I am open to some feedback, but this is really what I have been going off as a reference point for myself with these deployments. Another important factor is the retirement of Dual Forking and RCC in Wave 14 of OCS set to be released this year, existing OCS 2007 R2 implementations will be supported, however new deployments will not. This has made some companies forget about RCC implementations all together.
OCS 2007 R2 Schema Prep Failure “failure occurred attempting to check the schema state. please ensure active directory is reachable"
A customer called in today with an issue preparing their OCS 2007 R2 environment. The customer had previously started installation on a 2008 R2 server, and started over with a 2008 R1 server. They had only completed the Active Directory Preparations prior to starting over. The issue was when they started on the server they were unable to see the schema prep, they were receiving this error in the install GUI:
A few interesting things here, the machine is joined to the domain, I could contact all domain controllers, I could modify the schema using the schema MMC snapin. However, the OCS install run via command line or GUI would not contact active directory.
Through some quick googling I found that the installer queries the SRV records for contacting the PDC in active directory. This SRV record is:
After pointing to a DNS issue, the customer realized their server was pointing to a public DNS server, not an active directory integrated server, which did not have the SRV records needed to perform these tasks. Once the DNS server was changed, the installer read the Active Directory Preparation as Completed and you could do a proper nslookup on those SRV records