Note, however, that DrRez on Facebook and DrRez on Twitter will still be there for you—as the continuing voice for the NextHop Community on those channels.

Author: Susan S. Bradley, Microsoft Senior Content Project Manager

Publication date: March 27, 2013

Product version: Lync Server 2010

It is with some sadness that we are announcing the retirement of the DrRez blog, which launched in June 2010 for the primary purpose of showcasing the Microsoft Lync Server 2010 Resource Kit and the secondary purpose of creating a community channel for a continuing stream of Lync Server technical reference articles.

All articles currently posted to the DrRez blog will migrate to NextHop in April 2013. Lync Server 2013 technical reference content will be available later this spring in the Lync Server 2013 Technical Library.

In closing this chapter of our community content strategy, we are proud to say that as of February 2013, the DrRez blog ranks in the top 4% of all Microsoft TechNet blogs and has garnered nearly 500,000 page views since its launch.

In addition, downloads of Resource Kit chapters reached 250,000 in February 2013, well exceeding sales of previous versions of the print book. Our strategy to make the Lync Server Resource Kit available to customers at no cost was clearly the right approach.

We can’t say goodbye without thanking the cast of dedicated writers, technical reviewers, and editors that made the DrRez blog a trusted channel of Lync deep-dive, technical reference content. Without these folks, our dream to create and sustain this important channel could not have become a reality:

Andreas Strebel, Andrew Sniderman, Bernd Ott, Brandon Bernier, Brandon Taylor, Brian R. Ricks, Byron Spurlock, Chris Norman, Cindy Kwan, Curtis Johnstone, Dhigha Sekaran, Dustin Hannifin, Faruk Celik, Francois Doremieux, Frédéric Dubut, Geoff Clark, Hong Sodoma, Indranil Dutta, Janet Lowen, Jared Gradle, Jeff Schertz, Jerome Bernier, Jim Bradley, John Johnson, Kangmo Kim, Keith Hanna, Kelly Fuller Blue, Kent Tilger, Kurt De Ding, Lei Hua, Michele Martin, Mike Adkins, Mike Sneeringer, Mike Wood, Mitch Duncan, Namendra Kumar, Okan Gurer, Paul Adams, Philipp Beck, Rahul Indurkar, Riccardo Trocca, Rick Kingslan, Rick Varvel, Rob Pittfield, Roy Kuntz, Rui Maximo, Sam Gantner, Sankaran Narayanan, Sasa Juratovic, Scott Stubberfield, Seth Paul, Stéphane Cavin, Subbu Chandrasekaran, Susan S. Bradley, Taimoor Husain, Tarang Mittal, Thomas Binder, Tommy Larsson, Tonino Filipovic, Tracy Zheng, Vassili Kaplan, Wajih Yahyaoui, and Wayne Filin-Matthews.

And because the DrRez blog began as a vehicle for the delivery of the Microsoft Lync Server 2010 Resource Kit, we also want to acknowledge the tremendous effort of the writers, technical reviewers, and editors who created the Resource Kit:

Abdul Waraich, Ahmet Gyger, Ajay Chitturi, Ajit Kalele, Alex Hehmeyer, Alexandra Lise, Amey Parandekar, Antti Kiviniemi, Arish Alreja, Benjamin Chau, Bernd Ott, Brandon Bernier, Brandon Taylor, Brian R. Ricks, Byron Spurlock, Cameron Parker, Chris Eagan, Cindy Kwan, Conal Walsh, Dave Grob, Hong Sodoma, Dave Howe, Dustin Hannifin, Duy Tran, Edwin Young, Frédéric Dubut, Gang Peng, Gennady Kostinsky, Geoff Clark, Greg Anthony, Hao Yan, Humayun Khan, Indranil Dutta, Jamie Stark, Jared Gradle, Jason Bubolz, Jeffery Reed, Jens Trier Rasmussen, Jerome Berniere, Jim Bradley, Joe Schaeffer, Josh Marshak, Kam Toor, Kate Gleeson, Katrina Purcell, Kaushal Mehta, Keith Hanna, Kelly Fuller Blue, Ken Araujo, Kent Tilger, Kurt De Ding, Lei Hua, Lekshmi Menon, Ling Cao, Mahendra Sekaran, Mark Stafford, Marta Luis Burguete, Mei Lu, Michele Martin, Mike Sneeringer, Moustafa Noureddine, Neil Deason, Nick Smith, Oscar Antezana Chavez, Patrick Kelley, Paul Adams, Paul Brombley, Phillip Beck, Prasad Thota, Premal Gandhi, Radu Constantinescu, Ramesh Narayanan, Randy Wintle, Rick Kingslan. Rob Pittfield, Rob Young, Robbie Bikdash, Roy Kuntz, Rui Maximo, Sam Gantner, Samantha Woogerd, Satya Kondepudi, Seth Paul, Stefan Plizga, Stephane Cavin, Thomas Laciano, Stephen Wong, Steve Wood, Steven van Houttum, Stuart Birkett, Subbu Chandrasekaran, Susan S. Bradley, Taimoor Husain, Tarang Mittal, Thomas Lee, Tin Fan, Tom Laciano, Tony Bell, Tracy Zheng, Vassili Kaplan, Venkat Addanki, Vincent Valdez, Wei Zhong, Weiming Shen, William Looney, Xu Liu, and Yong Zhang.

Please join me in extending a big THANK YOU to all these great folks in the Comments below. We hope you have benefited from the information presented on the DrRez blog and look forward to connecting with you on NextHop.

NOTE   Microsoft Lync Server 2010 Protocol Workloads Poster version 5.15 is now available here.

Author: Rui Maximo

Publication date: November 2010

Revision date: June 6, 2012

Product version: Microsoft Lync Server 2010

Description

The Microsoft Lync Server 2010 Protocol Workloads Poster is an update of the Office Communications Server 2007 R2 protocol poster, which was released in 2009 and is still available. So many customers and professionals liked it and found it useful that they requested I update it for Lync Server 2010. Encouraged by the positive feedback, I made it a priority to release an updated poster for Lync Server.

Since the initial release early the week of November 15, 2010, customers and UC professionals sent in e-mails with positive comments and valuable feedback regarding inaccuracies and enhancements. Providing accurate information is important—every effort is made to quickly update the poster so that erroneous information isn’t disseminated.

To help you track the latest update of the poster, you’ll notice a version number in the upper-left corner of the poster. The current and latest update is marked as version 5.12. This version updates adds more detailed traffic information to the Enterprise Voice workload based on feedback from Richard Pasztor and Thomas Binder.

As the “guardian” of this poster, I’m committed to keeping the poster updated. You can download the poster from here. Hope you like it!

View this poster at Zoom.IT.

Purpose

Isn't eye-candy enough to serve as a purpose? You can print it and hang it in your office. Co-workers passing by will immediately be impressed by your technical prowess, and your manager will suddenly, to your surprise, give you a raise. We've heard customer stories reporting unexpected good luck coming their way. So, go ahead and plaster this protocol poster on your wall, and let the goodwill shower down on you.

In addition to good fortune, this poster provides an understanding of the protocols and ports used for each workload. By isolating the protocols for each media, you can gain a better understanding of how Lync Server works. This deeper understanding can help you troubleshoot problems with a specific media in your Lync Server deployment.

Because certificate configuration can be confusing, this poster also details which settings to define in the server certificate request. If you don't find these settings defined in the certificate issued, it is an indication that the server certificate wasn't properly requested from the certification authority (CA).

Domain Name System (DNS) is a configuration step that can often be missed and is prone to misconfiguration, particularly for Edge servers. The poster lists the DNS configurations that are needed for Lync Server.

Last, but not least, this poster has useful links to where you can obtain additional resources, such as articles, the Microsoft Office Communications Server 2007 R2 Resource Kit book, product documentation, and useful tools. You'll notice a Microsoft Tag. Take a picture with your mobile phone, and the picture will automatically resolve the embedded URL to NextHop. Here you'll find lots of useful technical articles and a community of like-minded technical professionals, such as yourself. The Microsoft Tag application must be installed on your phone. If you're not familiar with Microsoft Tag, you can get more information at microsoft.com/tag.

Summary

The Microsoft Lync Server 2010 Protocol Workloads Poster summarizes the protocols, ports, and certificate and DNS requirements for each workload in Lync Server. Having a visual snapshot of how the product works can be useful. If you would like to provide feedback, you can reach me at rui@maximo.ws.

Stay tuned for Microsoft Lync Server 2010 Firewall Poster to be released. I've heard that many customers (that's you, yes, you) would like to have it. Please check back on NextHop or follow DrRez on Twitter for an announcement of when it will be published.

Lync Server 2010 Resources

• Lync Server TechNet Library
• Microsoft Lync TechCenter
• Lync Server workload poster

We Want to Hear from You

• To give us feedback about this article or to propose a topic for an article, e-mail us at NextHop@microsoft.com.
• You can also send us a tweet at www.twitter.com/DrRez.

Keywords: Enterprise Voice; IM; presence; conferencing; application sharing; CAC; certificate; central management store; Edge Server; Mediation Server; Exchange UM; Mobility Server; Monitoring Server; Group Chat Server; Director; XMPP gateway; sip; rtp; srtp; stun; turn; psom; https; mtls; tls; dns;

The ABSConfig.exe has been updated. The update resolves an issue where the ABSConfig.exe tool does not save changes. For a description of the update see The ABSConfig.exe tool does not save the most recent changes in Lync Server 2010.

Author: Tracy Zheng

Publication date: January 2011

Update: May 9, 2012 

Product version: Microsoft Lync Server 2010

Introduction

The Address Book Service Configuration tool (ABSConfig) is an administrative tool that helps administrators customize the Address Book Service configuration in Microsoft Lync Server 2010 communications software. It also allows Lync Server 2010 administrators to restore the default Address Book Service settings. You can download this tool and other Microsoft Lync Server 2010 Resource Kit tools from the Download Center.

Description

ABSConfig is a graphical user interface application that enables administrators to configure Active Directory Domain Services attributes that are related to Address Book Service.

The primary scenarios for the tool are the following:

• To enable administrators to map attributes in Active Directory Domain Services to the attributes for Lync Server.
• To enable administrators to specify the Active Directory attribute to be included or excluded in the Address Book Service files.
• To enable administrators to restore default Address Book Service settings.

The ABSConfig tool can be started by using the absConfig.exe file. The tool opens to the Configure Attributes tab. This tab has options to map Active Directory attributes to the attribute fields for Lync Server and to specify which users to include or exclude in Address Book Service files based on specific attribute filters. It also has options to customize which value of the phone number to be included in the Address Book file. The Restore Defaults option enables administrators to restore Address Book Service settings to default values.

Output

ABSConfig stores the Address Book Service configuration in the database.

Path: %programFiles%\Microsoft Lync Server\Reskit

Purpose

ABSConfig provides a quick and easy way to customize Lync Server Address Book Service.

Requirements

Computer

ABSConfig can be run only from a domain-joined computer that has Lync Server installed. In the case of Microsoft Lync Server 2010, Enterprise Edition, this tool can be run on any Front End Servers that have the Address Book Service enabled during setup.

Network

The computer should be able to connect to the Front End pool and back-end database.

Software

Lync Server must be installed before running the ABSConfig tool.

Users

Administrators who have the permissions required to update the Lync Server deployment.

Example

ABSConfig can be started by typing ABSConfig.exe at a command prompt. Figure 1 shows the ABSConfig tool user interface.

Figure 1. ABSConfig tool UI

Summary

The ABSConfig tool provides administrators a quick and easy to use tool to customize Lync Server Address Book Service.

Keywords: Address Book Service; configuration; admin; ABSConfig; Active Directory; Domain Services; Front End; database; back end

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Author: Mike Adkins

Publication date: January 12, 2012

Product version: Lync Server 2010

Introduction

Any Lync Server 2010 infrastructure benefits from installing Lync Server 2010 Monitoring Service Reports. The variety of summary and diagnostics reports that are provided by the Monitoring Service Reports usually meet the needs of the Lync Server 2010 Voice over Internet Protocol (VoIP) network administrator. Some organizations may require the addition of proprietary reports that display additional information from the Lync Server 2010 Monitoring Service LcsCDR database. The prerequisite installation of the Microsoft SQL Server Reporting Services includes the SQL Server Report Builder tool, which provides a convenient way to access application or user-defined data sources that are hosted by Microsoft SQL Server databases. This makes the SQL Server Report Builder tool an excellent choice for creating additional Lync Server 2010 call details reports that meet the requirements of an organization's VoIP reporting services. This article is divided into two parts that explain the steps needed to create a Lync Server 2010 call details report based on specific information that is stored in the LcsCDR database. Part 1 of this article provides the step-by-step information that is needed to use the SQL Server Management Studio tools to design and create a SQL Server stored procedure that can be used as a data set for a custom Lync Server 2010 Monitoring Service Report. In this, part 2 of the article, I describe stepping through the SQL Server Report Builder Table or Matrix Wizard to create a data source, access data from database objects, design a report that includes summary information and user-defined functionality, and then to save that report.

Creating a custom call details report

The first step to creating a custom call details report for use with the pre-existing Lync Server 2010 Monitoring Service Reports is to establish a secure connection to the SQL Server and LcsCdr database objects that will be used as data sources for any new reports. Next, access will be provided to the user-defined database objects that reside in the LcsCDR database. Once the data is accessible, then it is time to present it by using the SQL Server Report tool. The SQL Server Report tool allows data to be presented as a chart, map, or as a table or matrix as shown in this article. Once the report is completed, it can be saved to the LyncServerReports folder for convenient access.

Accessing the LcsCdr database objects

Use SQL Server Report Builder tool in the following steps to access the LcsCdr database and the user-defined referredToPSTNFrom SQL Server stored procedure that will be used as the source of information for the new Lync Server 2010 call details report. This new report will be used to determine which Lync 2010 users have used the call forwarding feature to forward their incoming calls to the public switched telephone network (PSTN).

1. From a browser, open the SQL Server Reporting Services home page by entering its URL in the browser’s address line. For example: server01/Reports.

2. Click the Report Builder link to access the SQL Server Report Builder wizard (see figure 1).

Figure 1. Opening SQL Server Reporting Services

3. Click New Report, and then click Table or Matrix Wizard (see figure 2).

Figure 2. Starting the SQL Report Builder Wizard

4. Select the Create a new dataset option on the Choose a dataset page, and then click Next (see figure 3).

Figure 3. Selecting a dataset from the LcsCDR database

5. On the Choose a connection to a data source page, click Browse to locate the preexisting CDRDB data connection object.

6. In the Select data source dialog box, select the CDRDB data connection object, and then click Open.

7. On the Choose a connection to a data source page, click Next .

8. In the Database view window on the Design a query page, expand the stored procedures node and check the stored procedure that will be used for the new report. Click Next (see figure 4).

Figure 4. Select the data source for the report

Designing and previewing the report

The next section of this article will walk through the design phases of the report, previewing the report, and saving the report to the SQL Server Reporting Service LyncServerReports folder.

1. Use the Arrange fields page of the New Table or Matrix wizard to arrange the fields for the report in column and row fashion. Row grouping places similar information together in the report. Column groups are displayed from left to right across the report. Summary values such as count, sum, average, maximum, and minimum are used to calculate values contained in the Row groupings (see figure 5).

Figure 5. Arranging the fields for the report

2. To design the report’s layout, on the Choose the layout page, make sure the defaults are checked, and then click Next.

3. Use the Choose the style page to apply one of the predefined layouts to the report, and then click Next (see figure 6).

Figure 6. Selecting the style for the report

4. Use the SQL Server Reporting Service report designer to add finishing touches to the report. You can add a title for the report, adjust column widths, add built-in fields if you want, and add any other user-defined touches to enhance the report (see figure 7).

Figure 7. Working with the report in design view

5. To preview the report, on the toolbar, click Run, or press F5 on the keyboard. Remove the checks from the default parameter Null checkboxes and add the needed parameter values, for example the beginning and ending dates, and then click View Report to preview the report.

6. With the report in full view you can make derminations on how the report should be formatted for optimal viewing. Also, notice the “+” in the column headings. This feature allows the viewer to expand that column to view more detailed information (see figure 8). 
Figure 8 – Previewing the report

7. Once you have formatted the report, click File, click Save, and then save it to the following location: LyncServerReports\Reports_Content folder. Now the report can be accessed from the SQL Server Reporting Services LyncServerReports page by clicking its link (see figure 9) .
Figure 9. Saving the report to LyncServerReports folder 

Summary

The installation of the Lync Server 2010 Monitoring Server Reports provides a set of predefined reports that are used for Lync Server 2010 VoIP call analysis. This is useful when additional Lync Server 2010 call details reporting is needed for more detailed analysis of VoIP call traffic on a network. The default installation of the SQL Server Report Builder tool that is included with the Monitoring Server Reports installation can be used for easy access to any additional information in the LcsCDR database. This additional information can be utilized for reporting purposes. The SQL Server Report Builder wizard will allow the creation of maps, charts, and table or matrix reports that can display this additional Lync Server 2010 VoIP call information. Once created, these reporting objects can be saved to and then accessed from the LyncServerReports folder on the SQL Server Reporting Services home page.

Additional Information

• Microsoft Lync Server 2010 Resource Kit: Archiving and Monitoring
• Microsoft Lync Server 2010 Resource Kit

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• DrRez blog
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Author: Mike Adkins

Publication date: January 9, 2012

Product version: Lync Server 2010

Introduction

The Lync Server 2010 Monitoring Server Reports provide customers with a set of predesigned reports that provide the diagnostic and the summary details for audio/visual (A/V) calls that are managed in the Lync Server 2010 environment. Installing the Lync Server 2010 Monitoring Service adds the LcsLog (archiving) and the LcsCDR (call details) databases to the SQL Server instance that manages data for the Lync Server 2010 Monitoring Service. The predesigned Monitoring Server Reports may not provide all the information that is needed by an organization to completely assess the use of their networks Voice over Internet Protocol (VoIP)-enabled clients. Any need for additional A/V call detail reporting could require the design and implementation of new database objects for the LcsCDR database, a data source connection, and the reports that will display the additional A/V call detail information.

This article is divided into two parts that explain the steps needed to create a Lync Server 2010 call details report based on specific information that is stored in the LcsCDR database. Part 2 of this article will provide the step-by-step information for using the Microsoft SQL Server Report Builder to create the data connection to the new SQL Server stored procedure and the new Lync Server 2010 call details report that will display that stored procedures information.

Designing and creating the database objects

Whether you create a new Lync Server 2010 call details report is dependent on the availability of the data that the report will present. You can use Microsoft SQL Server Management Studio to display all of the LcsCDR database’s tables and their contents so you can inspect the information that may be used for a new report. Just expand Tables node under the LcsCDR database (see Figure 1).

Important SQL Server requires the delegation of its security model to the user account that will access the SQL Server, perform SQL Server configuration updates, read and write information that is stored in its databases and perform design updates to databases. For detailed information on managing SQL Server permissions, see the “Additional Information” section of this article.

Figure 1. Using SQL Server Management Studio to analyze information in the LcsCDR database

To view additional information stored in the Lync Server 2010 Monitoring Service LcsCDR database, you need to create the SQL Select queries that will be used as the basis for the report’s SQL Server stored procedure. The SQL Select query will allow the extraction of information from the tables in the LcsCDR database that contain information needed for the report. A SQL Select statement allows the use of SQL Join syntax to extract related information from multiple tables in a database. The simple SQL Select query example that is provided (see Figure 2) will use a SQL Select statement with a simple SQL Inner Join and SQL Where clause. The purpose of the Inner Join is to display the number of rows of information in a secondary table that contains a key value that matches the key value for one row in the primary table. In practice the secondary table will contain many matches for the key value that is listed only once in the primary table. This determines the range of data and the overall number of rows returned by the SQL Select query. The SQL Where clause is used to determine the type and amount of information that is returned by the SQL Select query based in the criteria defined by it.

Note: This article will not go into detail on the many uses of SQL syntax. For details about using basic SQL Select statements, see the SQL Server Search option from the Help menu of SQL Server Management Studio.

Creating a SQL query

The SQL Select query created in this example provides information that can be used to determine which Microsoft Lync 2010 users have used the enabled call forwarding feature to forward their incoming calls to the public switched telephone network (PSTN). This information will be displayed in a Lync Server 2010 Call Details Report that can be used to track the cost of this type of call to the PSTN (see Figure 2). The Select query will extract information from two tables that are part of the LcsCdr database. The primary table for the SQL Select query is named Users. The Users table contains a record for each Lync 2010 user that initiates an A/V call. The secondary table is named SessionDetails. The SessionDetails table contains a record of each A/V call that is managed by the Lync Server 2010 Voice over IP (VoIP) environment. The key fields in each table that will host the Inner Join are Users.UserId and SessionDetails.ReferredById. Each of these fields contains an integer value that represents the Lync A/V caller’s UserId. With the Inner Join defined in this manner, the SQL query will display the user’s SIP Uniform Resource Identifier (URI) that referred or forwarded the incoming A/V call from another local Lync 2010 user to the PSTN.

The following procedure shows how to create the SQL Select query statement for analyzing A/V calls that have been forwarded by a specific Lync 2010 user to the PSTN.

To create the SQL Select query statement

1. Open the SQL Server Management Studio console.

2. On the SQL Server Management Studio’s toolbar, click New Query to open a SQL Server query window.

3. Use the SQL Server query window to design and test the query that will be used as the data source for the new A/V call detail report.

4. To test and view the results of the new query, click Execute, as shown in Figure 2.

5. Save the contents of the SQL Server query window as a file with a .sql extension.

Figure 2. Creating and testing a SQL Select query

Create a SQL Server Stored Procedure

A SQL Server stored procedure is a database object that contains procedural instructions that are defined in SQL syntax. It’s useful because of its portability. In this example the SQL Server stored procedure is designed to contain the SQL Select query statement that we defined in the “Creating a SQL Query” section of this article. This SQL Server stored procedure allows the entry of the BeginDate and EndDate parameters to be passed to the SQL Query’s Where clause.

Creating a SQL Server stored procedure requires three steps:

• Create the SQL Server stored procedure template
• Add the SQL Select query’s code to the SQL Server stored procedure template
• Test the SQL Server stored procedure

To create the SQL Server stored procedure template

1. Use the SQL Server Management Studio object browser to locate the LcsCDR database that is listed under the user database objects.

2. Expand the LcsCDR database, and then expand the Programmability node.

3. Right-click the Stored Procedures node, and then click New Stored Procedure.

4. The SQL Server query window will now display the SQL Server Create Stored procedure template, as shown in Figure 3.

Figure 3. The SQL Server Create Stored procedure template

The next step in the stored procedure creation process is to add the SQL Select query’s code (see Figure 2) to the SQL Server stored procedure template.

To add the SQL Select query’s code

1. Add the name for the stored procedure to the right of the Create Procedure clause of the SQL Server stored procedure template, as shown in Figure 3.

2. Copy and paste the SQL query @BeginDate and @EndDate parameters from the SQL query that is described in the “Creating a SQL Query” section of this article into the parameters section of the SQL Server stored procedure template, as shown in Figure 3.

3. Copy and paste the SQL query Select statement from the SQL query that is described in the “Creating a SQL Query” section of this article into the “Insert statements for procedure here” section of the SQL Server stored procedure template, as shown in Figure 3.

4. To create the new SQL Server stored procedure, click Execute, as shown in Figure 4.

Figure 4. Adding the SQL Select query syntax for the new SQL Server stored procedure

The last step in the creating database objects procedure is to test the new SQL Server stored procedure to make sure that it works as expected.

To test the SQL Server stored procedure

1. Open the SQL Server Management Studio console.

2. From the toolbar, click New Query to open a SQL Server query window.

3. Select the LcsCDR database from the database selector on the toolbar.

4. Use the SQL Server query windows to type the following (as shown in Figure 5):

Execute <name of stored procedure> <paramerter1>, <parameter2>…

5. To test and view the results of the new query, click Execute.

Figure 5. Running the new SQL Server stored procedure

Summary

You need only a limited amount of knowledge of SQL Server Management Studio tools to use the A/V conferencing information that is stored in the LcsCDR database to create custom call details reports. Using SQL Select queries to analyze A/V call detail information provides insight into how specific information can be extracted from the LcsCDR database as presentation material for a call details report. The use of the SQL Server stored procedure database object provides a convenient way to manage access to the data that will be presented by the call details report. The second part of this article will provide a step-by-step process on how to access the output of SQL Server stored procedures from a SQL Server Report Builder report.

Additional Information

For more details about creating additional Lync Server 2010 Monitoring Server Reports, see chapter 2 of the Lync Server 2010 Resource Kit:

• Microsoft Lync Server 2010 Resource Kit

For more details on managing SQL Server permissions:

• Permissions Hierarchy (Database Engine)
• Permissions of Fixed Database Roles (Database Engine)

Support topics include:

• Key Resources
• Community
• Self Support Options
• Assisted Support Options
• Support Lifecycle

To stay up-to-date on the latest support issues, subscribe to the Top Microsoft Lync, Office Communications Server and Office Communicator Solutions from Microsoft Support RSS feed.

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• DrRez blog
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Authors: Randy Wintle, Dustin Hannifin

Publication date: August 2011

Product version: Lync Server 2010, Lync 2010

The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Lync Server 2010. The book will focus on professionals who want to understand more about how the product works internally. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

Internals (technical details of remote user access capabilities) are discussed in depth in this chapter and figure prominently in the scenarios. An introduction to the Interactive Connectivity Establishment (ICE) protocol, Simple Traversal Underneath NAT (STUN), and Traversal Using Relay NAT (TURN) implementations in Lync Server are provided.

Lync Server 2010 allows users to access instant messaging (IM) and presence remotely by using the Lync Server Access Edge service. The scenarios in this chapter describe remote IM and presence in remote user access, federation, and public IM connectivity.

Summary

The most common call flow scenarios that involve remote user access are described in detail and as follows:

• Instant Messaging: peer-to-peer, internal user to federated partner, and internal user to PIC user.
• Conferencing: application sharing conference (desktop sharing), and audio and video Conferencing.
• Enterprise Voice: peer-to-peer audio, involving two remote participants; peer-to-peer audio, involving a federated partner; and a PSTN gateway audio call, involving a remote user.

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Keywords: Presence, IM, instant messages, Enterprise Voice, peer to peer, conferencing, PSTN, gateway, remote access, federated, user, partner,

You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

Author: Andreas Strebel with Roy Kuntz, Mahendra Sekaran, and Radu Constantinescu

Publication date: April 2011

Revision date: August 2011

Product version: Microsoft Lync Server 2010

As stated in the original Enterprise Voice chapter release, Lync Server 2010 builds on the Enterprise Voice features introduced in Communications Server and Communications Server 2007 R2 and introduces several features that are required for an enterprise to consider Lync Server as a viable replacement option for their telephony infrastructure. The following new voice features are covered in this chapter:

• Call park and retrieve
• Enhanced 9-1-1 (E9-1-1)
• Private line
• Routing enhancements
• Call Admission Control

Summary

With the introduction of the new Enterprise Voice features in Lync Server and the strength of the existing features, Lync Server is a viable option for organizations to replace their current telephony infrastructure.

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Keywords: voice, E911, private line, routing, call park, orbit, locations, call admission control, (CAC),

Author:  Mike Adkins

Publication date: August 2, 2011

Product version: Office Communications Server 2007 R2

Introduction

The Office Communications Server 2007 R2 LCSEnableConfigureUsers.wsf script demonstrates how a Visual Basic script can be used to access the Windows Management Interface (WMI) and to update user accounts that reside in the local Active Directory Domain Services domain. The LCSEnableConfigureUsers.wsf script automates enabling and configuring users belonging to the local Active Directory Domain Services domain. These Communications Server users may reside in the Users container or in user defined Organizational Units. Using the LCSEnableConfigureUsers.wsf script does not require membership in the local Domain Admins group or access to the console of the Office Communications Server. The LCSEnableConfigureUsers.wsf script allows members of the RTCUniversalUserAdmins group to access and perform updates to local Active Directory Domain Services domain user account through the WMI.

Description

To use the LCSEnableConfigureUsers.wsf script, two text files must be manually configured. First, configure the user file that contains the Active Directory Domain Services distinguished name (DN) path to the containers or organizational units that manage the domain user accounts. Second, configure the file that contains the Office Communications Server 2007 R2 user configuration and home server or pool distinguished name (DN). The LCSEnableConfigureUsers.wsf script uses the information listed in the user file, to traverse the organizational units and default Users container in the Active Directory Domain Services domain. It then enables and configures user account objects to meet the specifications listed in the configuration files.  

User Configuration Information

Configuration updates are applied to the specified user accounts using the Communications Server WMI class MSFT_SIPESUserSetting. These Communications Server user account updates are applied to newly enabled Communications Server user accounts or as configuration updates to pre-existing Communications Server user accounts.

The MSFT_SIPESUserSetting  WMI class properties used as part of the Communications Server user account creation or configuration update process are listed below:

Enabled (boolean)

EnabledForFederation (boolean)

EnabledForInternetAccess (boolean)

EnabledForEnhancedPresence (boolean)

PublicNetworkEnabled (boolean)

RemoteCallControlTelephonyEnabled (boolean)

ArchiveInternalCommunications (boolean)

ArchiveFederatedCommunications (boolean)

AllowOrganizeMeetingWithAnonymousParticipants (boolean)

IPPBXSoftPhoneroutingEnabled (boolean)

UCEnabled (boolean)

MeetingPolicy (string)

PresencePolicy (string)

LocationProfile (string)

UCPolicy (string)

To function, the configuration.txt file requires at least one line entry in the LCSEnableConfigureUsers.wsf script. That line requires a unique prefix along with the DN of the Communications Server pool or Front End Server. For example:

For Communications Server Enterprise Edition

HomeServerDN:=CN=LC Services,CN=Microsoft,CN=Pool01,CN=Pools,CN=RTC Service,CN=Configuration,DC=contoso,DC=com 

For Communications Server Standard Edition

HomeServerDN:=CN=LC Services,CN=Microsoft,CN=Server01,CN=Pools,CN=RTC Service,CN=Configuration,DC=contoso,DC=com

When saved to the configuration.txt file, the previously listed DN information allows the LCSEnableConfigureUsers.wsf script to enable users, defined in the users.txt file, for Communications Server and Enhanced Presence. This is the default action for the LCSEnableConfigureUsers.wsf script.

MSFT_SIPESUserSetting WMI class properties must be added to the configuration.txt file one line at a time. Append “:=” to the end of each WMI property to denote the following designated value for that WMI property.  See the following example:

UCEnabled :=true

LocationProfile:=ContosoLocationProfile

Before adding a list of WMI properties to the configuration.txt file, some possible caveats should be considered to ensure the LCSEnableConfigureUsers.wsf script completes its task.

• The AllowOrganizeMeetingWithAnonymousParticipants feature is overridden when the global Communications Server Meeting policy’s Anonymous Participants setting is not set to Enforce per user.
• The RemoteCallControlTelephonyEnabled feature will fail if set to true when enabling a new Communications Server user account. This occurs because the new account does not have LineURI and ServerLineURI values already in place.
• The RemoteCallControlTelephonyEnabled feature will fail if set to true when the pre-existing Communications Server user account is Enterprise Voice enabled.
• The RemoteCallControlTelephonyEnabled feature can be used to toggle the pre-existing RCC enabled user account between RCC enabled or RCC disabled.
• The UCEnabled feature can be set to true after enabling a new Communications Server user account.
• If the value for the LocationProfile property string value does not match an existing Communications Server Location Profile, the user configuration will complete without error and the Communications Server user will not have a location profile associated with their Enterprise Voice enabled Communications Server user account.
• The MeetingPolicy WMI property requires that the global Communications Server Meeting policy’s Policy settings, Global settings are set to Use per user policy. The MeetingPolicy value is the meeting name, a string descriptor. The meeting name value must be a string with no spaces in it. If the meeting name assigned to MeetingPolicy has spaces, it will not be assigned to the MeetingPolicy WMI property by the LCSEnableConfigureUsers.wsf script.
• The UCPolicy WMI property requires that the global Communications Server Voice policy’s Global Policy settings be set to Use per user policy. The UCPolicy value is the enterprise voice policy name. The enterprise voice policy name value must be a string descriptor with no spaces. If the meeting name assigned to UCPolicy has spaces, it will not be assigned to the UCPolicy WMI property by the LCSEnableConfigureUsers.wsf script.
• The PresencePolicy WMI property requires that you create a custom Office Communications server presence policy before implementing the LCSEnableConfigureUsers.wsf script. For more detailed information on implementing a custom Office Communications server presence policy see: Configuring Presence Policies Using Configure Policies Script
• If you add entries to disable Remote Call Control and enable Enterprise Voice to the configuration.txt file, the pre-existing Communications Server user account will be disabled for Remote Call Control and enabled for Enterprise Voice.  See the following example

RemoteCallControlTelephonyEnabled:=false

UCEnabled:=true

• If you add the entries to enable Remote Call Control and disable Enterprise Voice to the configuration file, the pre-existing Communications Server user account will be disabled for Enterprise Voice and enabled for Remote Call Control. See the following example:

RemoteCallControlTelephonyEnabled:=false

UCEnabled:=true

User Information

The LCSEnableConfigureUsers.wsf script uses two different prefixes, specified in the users.txt file, to create and configure Communications Server user accounts. The two prefixes require that the line in the user’s file, which describes the user account, is prefixed with DN: or EMAIL: Here’s how it works:

DN:CN=Alan Brewer, OU=Users,OU=Communications Server,DC=contoso,DC=com

EMAIL:cycarey@contoso.net

Each line shown above can be used separately in the user.txt file. Each line creates an enabled Communications Server user or updates a pre-existing Communications Server user. The similarities between the two lines are:

• The DN: prefix provides the user accounts distinguished name (DN) in its context.
• The EMAIL: prefix points to the email address associated with the user account, in Active Directory Domain Services that retrieves the user account’s DN.

The differences between the two lines are:

• The DN: prefix assigns a SIP URI, to the newly enabled Communications Server user account that uses a domain suffix that matches the user’s DN. Before the Communications Server enabled account can be used, the user account’s DN domain suffix must match the domain suffix of a supported Communications Server SIP domain.
• The EMAIL: prefix assigns a SIP URI to the newly enabled Communications Server user account that uses a domain suffix of the email address associated with the user account. Before the Communications Server enabled account can be used, the email address’s domain suffix must match the domain suffix of a supported Communications Server SIP domain.
• The DN: or EMAIL: prefix relies on the distinguished name (DN) of the pre-existing Communications Server user account to perform configuration updates.

To enable multiple Communications Server user accounts or to update multiple pre-existing Communications Server user accounts, the DN: prefix can include the Organization Unit (OU) the user accounts belong to.

Here is the DN: line used to enable Communications Server user accounts or to update multiple pre-existing Communications Server user accounts in the Users OU:

• DN:OU=Users,OU=Communications Server, DCcontoso,DC=com

Warning: it is not recommended to use DN: to point to the Active Directory Domain Services default Users container, for example, DN:CN=Users,DC-contoso,DC=com. This user.txt file entry forces the LCSEnableConfigureUsers.wsf script to enable and configure all user accounts and contacts located in thee Users container.

After Communications Server user accounts are initially enabled and configured, the LCSEnableConfigureUsers.wsf script can be used to reconfigure specific Communications Server user accounts using the DN:, EMAIL:, or SIP: prefixes in the users.txt file. For example you can use the prefixes to update specific Communications Server enabled accounts:

SIP: abrewer@contoso.com

EMAIL: cycarey@contoso.com

DN:CN=Florence Flipo,OU=Users,OU=Communications Server,DC=contoso,DC=com

The LCSEnableConfigureUsers.wsf script can be used to reconfigure multiple Communications Server user accounts using the DN: prefix in the users.txt file. For example you can use DN to update all Communications Server enabled accounts in the Users OU: 

DN: OU=Users,OU=Communications Server, DC=contoso,DC=com

Output

The LCSEnableConfigureUsers.wsf script can enable and perform configuration updates to individual or multiple Communications Server user accounts. The LCSEnableConfigureUsers.wsf script updates Active Directory Domain Services user accounts that reside in a Communications Server enabled user’s domain. The Office Communications Server Active Directory preparation adds the msRTCSIP* attributes to all user accounts in the domain hosting Communications Server. By design, msRTCSIP* user attributes can be accessed through MSFT_SIP*WMI classes which are enabled locally during the installation of Communications Server. The LCSEnableConfigureUsers.wsf script performs requested updates on specified instances of the MSFT_SIPESUserSetting class properties. Updated MSFT_SIPESUserSetting class properties are then replicated to their corresponding msRTCSIP* user attributes in the Communications Server prepped Active Directory domain.

Warning: The LCSEnableConfigureUsers.wsf script is a powerful tool that can also affect the configuration of Active Directory Doman Services user accounts that are not enabled for Communications Server. Use the LCSEnableConfigureUsers.wsf script in a test lab environment using the constraints mentioned above before running it in your environment. Learning to correctly use the LCSEnableConfigureUsers.wsf script provides administrators with a quick and effective way to enable new and re-configure existing Communications Server users.

Purpose

The LCSEnableConfigureUsers.wsf script provides non domain administrators with an efficient way to update and enable Communications Server user accounts. Because the LCSEnableConfigureUsers.wsf script does not have to run from the Communications Server console, it provides administrators with remote access.

Requirements

The Communications Server Resource Kit tools are supported on the following Window Server operating systems:

• Windows Server 2003 Standard Edition operating system with Service Pack 2.
• Windows Server 2003 Enterprise Edition operating system with Service Pack 2.
• Windows Server 2008 operating system.
• The LCSEnableConfigureUsers.wsf script requires the domain user to be a member of the RTCUniversalUserAdmins group. Group membership grants permissions needed to enable and update Communications Server user accounts
• The LCSEnableConfigureUsers.wsf script requires the installation of the Communications Server Administrative tools to access to the Communications Server WMI.

Examples

The LCSEnableConfigureUsers.wsf script can be run from a command line window on a computer that has the Communications Server administrative tools installed on it. The LCSEnableConfigureUsers.wsf script requires the configuration of two text files. These text files contain the user account location information and the intended user configuration information. Here are three configuration examples of user.txt and configuration.txt:

Enabling all Communications Server users for Enterprise Voice

Users.txt

DN:OU=Users,OU=Communications Server,DC=contoso,DC=com

Configuration.txt

Enabled:=true

UCEnabled:=true

EnabledForEnhancedPresence:=true

IPPBXSoftPhoneroutingEnabled:=true

MeetingPolicy:=VoIPConferencing

LocationProfile:=ContosoLocationProfile

UCPolicy:=ContosoEnterpriseVoicePolicy

Updating a single Communications Server for Remote Call Control

Users.txt

SIP:abrewer@contoso.com

Configuration.txt

RemoteCallControlTelephonyEnabled:=true

Enabling one Communications Server user for Enterprise Voice

Users.txt

DN:CN=Florence Flipo,OU=Users,OU=Communications Server,DC=contoso,DC=com

Configuration.txt

Enabled:=true

EnabledForFederation:=true

EnabledForInternetAccess:=true

EnabledForEnhancedPresence :=true

PublicNetworkEnabled:=true

ArchiveInternalCommunications:=true

ArchiveFederatedCommunications:=true

AllowOrganizeMeetingWithAnonymousParticipants:=true

UCEnabled:=true

IPPBXSoftPhoneroutingEnabled:=true

MeetingPolicy:=VoIPConferencing

LocationProfile:=ContosoLocationProfile

UCPolicy:=ContosoEnterpriseVoicePolicy

Using LCSEnableConfigureUsers.wsf  from the Command Line

The LCSEnableConfigureUsers.wsf script can be run from a command prompt window as follows: 

C:\Tools> LCSEnableConfigureUsers.wsf /usersFile:users.txt /configFile:configuration.txt

To record the positive or error feedback add the “>” operator to the end of the command line and point it to the folder where you want the log file stored. For example: 

C:\Tools> LCSEnableConfigureUsers.wsf /usersFile:users.txt /configFile:configuration.txt > C:\output.txt

When the LCSEnableConfigureUsers.wsf script completes its process, view the output.txt file for the results of the command.

Summary

The LCSEnableConfigureUsers.wsf script allows non domain administrators to perform Active Directory updates on Communications Server user accounts from a remote location. To use the LCSEnableConfigureUsers.wsf script from a non-Communications Server computer, you must install the Communications Server Administrative tools on the local machine. Important: exercise caution when using the LCSEnableConfigureUsers.wsf script. When improperly used, the script tries to apply Communications Server updates to all user accounts in the Active Director Domain Services container. When used correctly; however, the LCSEnableConfigureUsers.wsf script is an efficient and powerful tool for administering Communications Server user accounts.

Additional Information

To learn more, check out the following articles:

• Office Communications Server 2007 R2 Resource Kit Tools
• Configuring Presence Policies Using Configure Policies Script

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Keywords: LCSEnableConfigureUsers.wsf, communications, server, user, configure, script

Author: Mike Adkins

Publication date: July 2011

Product version: Office Communications Server 2007 R2

Introduction

LCS Verify Clean, a tool in the Office Communications Server 2007 R2 Resource Kit, is a straightforward command-line utility (LcsVerifyClean.vbs). LcsVerifyClean provides Office Communications Server administrators with diagnostic information that can be useful in detecting the cause of product installation failures that are sometimes caused by faulty Office Communications Server uninstallations. LcsVerifyClean provides Office Communications Server administrators with step-by-step guidance through the tricky process of removing Office Communications Server products. You can download this tool and other Office Communications Server 2007 R2 Resource Kit tools from the Download Center.

Description

The Office Communications Server set-up program checks for the remnants of prior installations of Office Communications Server. The set-up program may halt the installation process if legacy Office Communications Server information is detected locally on the computer that is running Windows Server. LcsVerifyClean verifies that your computer is clean of Office Communications Server product binaries, registry keys, and Windows Management Instrumentation (WMI) classes that may belong to a prior installation of Office Communications Server. LcsVerifyClean outputs the needed step-by-step uninstallation instructions to the Command Prompt window that it is run from. This process helps ensure the uninstallation of Office Communications Server from a computer running Windows Server.

Output

If LcsVerifyClean locates any legacy information, the tool provides the location of the unwanted information, and then prompts the administrator to remove it from the system before again running LcsVerifyClean from its Command Prompt window. For instance, when LcsVerifyClean locates Office Communications Server binaries that are installed on the computer running Windows Server, LcsVerifyClean will prompt the administrator to remove the preexisting binaries by using Add/Remove Programs in Control Panel in Windows Server 2003 or Program Features applets in Windows Server 2008 (see Figure 2). If LcsVerifyClean locates no legacy Office Communications Server information on the computer running Windows Server, the tool provides output as shown in Figure 1.

Figure 1. LcsVerifyClean shows the computer running Windows Server is clean of any legacy Office Communications Server information

Purpose

LcsVerifyClean has been available for use with both Office Communications Server 2007 R2 and Office Communications Server 2007. Each new release of LcsVerifyClean has been designed to check for the previous versions and the current version of Office Communications Server on the computer running Windows Server that hosts Office Communications Server. Using LcsVerifyClean as a preliminary step during the installation process of Office Communications Server helps ensure a trouble-free installation of Office Communication Server. Moreover, using LcsVerifyClean as the last step of the uninstallation process for an Office Communications Server uninstallation ensures that the computer running Windows Server that is to be re-purposed has no legacy Office Communications Server binaries, registry entries, or WMI information. The LcsVerifyClean uninstallation process begins with the manual uninstallation of any preexisting Office Communications Server binaries by using either of the following:

• Windows Server 2008: Program Features applets
• Windows Server 2003: Add/Remove Programs in Control Panel

After all preexisting Office Communications Server binaries have been removed, subsequent uses of LcsVerifyClean check for unwanted registry entries, installation folders, and WMI information. When the clean-up operation is complete, LcsVerifyClean will return information that is similar to Figure 1.

Requirements

The Office Communications Server 2007 R2 Resource Kit tools are supported on the following Window Server operating systems:

• Windows Server 2008 operating system
• Windows Server 2003 Standard Edition operating system with Service Pack 2 (SP2)
• Windows Server 2003 Enterprise Edition operating system with Service Pack 2 (SP2)

LcsVerifyClean requires the equivalent permissions from a member of the Domain Admins group in the Active Directory Domain Services domain that is hosting the Office Communications Server installation.

Examples

An Office Communications Server installation may be halted if the installation program detects any previously installed Office Communications Server information on the computer running Windows Server. LcsVerifyClean can determine the cause of the Office Communications Server installation failure (see Figure 2).

Figure 2. LCS Verify Clean displays the Office Communications Server binaries that need to be removed

Figure 2 recommends either of the following to remove the prior Office Communications Server installation application data from the system:

• Windows Server 2008: Program Features applets
• Windows Server 2003: Add/Remove Programs in Control Panel

Note The use of the Windows Installer Cleanup Utility in Figure 2 is no longer distributed or recommended by Microsoft. For details, see How do I uninstall Office 2003, Office 2007 or Office 2010 suites if I cannot uninstall it from Control Panel?

After the uninstallation of residual Office Communications Server applications from the computer that is running Windows Server, running LcsVerifyClean again displays legacy registry information that can halt the installation of Office Communications Server (see Figure 3).

Figure 3. LcsVerifyClean displays legacy registry information that needs to be removed

The error information in Figure 3 suggests removing legacy Office Communications Server registry information that is located at HKLM\Software\Microsoft\Real-Time Communications by using the registry editor tool on the computer running Windows Server (see Figure 4).  

Warning: Before your delete any registry information, export (back up) this information as a .reg file to a safe location.

Figure 4. Use the Windows Server registry editor to remove the unwanted registry information

The legacy Office Communications Server uninstallation may now be complete. To confirm this, use the LcsVerifyClean tool one more time to ensure that its output matches the information in Figure 1.

Summary

Using the Office Communications Server 2007 R2 Resource Kit LCS Verify Clean tool to ensure the complete uninstallation of Office Communications Server from a computer running Windows Server is a sound preventive measure to take before re-purposing that server.

The challenge of a failed Office Communications Server installation can be met through the proper use of LcsVerifyClean to help ensure that residual Office Communications Server information is not preventing the installation. LcsVerifyClean has been updated and is reliable when used with either Office Communications Server 2007 R2 or Office Communications Server 2007.

Additional Information

For more information, see the following:

• Office Communications Server 2007 R2 Resource Kit Tools
• How do I uninstall Office 2003, Office 2007 or Office 2010 suites if I cannot uninstall it from Control Panel?

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Keywords: WMI, removal, setup, failure, uninstallation