Search This Blog

Sunday, February 25, 2018

Cannot login to Exchange 2013/2016 Exchange Control Panel

We recently started our migration from Exchange 2010 SP3 (RUP18) to Exchange 2016.
After installing Exchange 2016, we ran in a heap of trouble when opening the Exchange 2016 Administrative Center, or when we tried to open OWA on Exchange 2016.

When browsing ECP/OWA, we would not even receive a login screan, We merely got "500 Unexected Error".

Searching the internet lead me to following Technet Forum post:

After removing the value's in MSEXchCanaryData, and recycling the Application pools in IIS I was able to login.
You have to open the ADSI editor on the primary domain controller (start-->administrative tools-->ADSI edit), go to CN=Services --> CN=Microsoft Exchange --> CN=  Right click CN=Client Access and click properties.  Scroll down to msExchCanaryData0.  You have to click edit and copy the data from Data0, Data1 and Data2 (you may have more or less) to a notepad file.  Then erase the data from those settings.  Now log onto the CAS server and open IIS management.  Go to application pools and  right click MSExchangeOWAAppPool and click Recycling.  Then restart all of the mailbox servers.  
[Quote]Marshall Lucas[/unquote]

A collegae tried to login as well, but he failed. He did get a login screen but after logging in he would still received " 500 Unexected Error". It could not be an infrastructural problem because i was able to login, wherefore we excluded any issue on part of ISS. We compared both our admin accounts and discover that my admin account was fitted with a mailbox (probably created during a test, and neglected to clean afterwards). We enabled his account with a mailbox, and now he was able to login.

I know from experience that Administrator do not need a mailbox to logon to ECP, if the Administrator does not have a mailbox attached, it would use a system mailbox instead. So the next step was to verify the arbitration mailboxes:

Get-Mailbox -arbitration | fl name, DistinguisgedName

Which returned me 5 arbitration mailboxes, 3 SystemMailboxes, one discoverymailbox and one Migration mailbox. Which looks more or less OK, wherefore i dismissed that the issue was being caused by the lack of a missing arbitration mailbox.

Moved all retrieved arbitration mailboxes to Exchange 2016, but it did resolve the issue either.

Whent on seaching for two more days, and everything kept on pointing in the direction of a missing arbitration mailbox. I decided to verify the accounts in AD against the mailboxes retrieved from Powershell:

Get-Mailbox -arbitration | fl name, DistinguisgedName

Get-ADUser -Filter "Name -like 'SystemMailbox*'" -server Root

Where i saw the catch, In Active Directory we had 6 SystemMailbox accounts, and we only had 3 SystemMailboxes which we actually mailbox enabled. I decided to make every SystemMailbox account mailbox enabled, which resolved the issue.

Get-ADUser -Filter "Name -like 'SystemMailbox*'" -server Root -Property Mail | ? {$_.Mail -eq $null} | foreach {Get-User $_.DistinguishedName | Enable-Mailbox -Database "Exchange2016DB"}

Monday, February 13, 2017


Do not use the server FQDN for the Identity in the Move-ADDirectoryServerOperationMasterRole Cmdlet, it will fail if you do:

Move-ADDirectoryServerOperationMasterRole -Identity "DC001.domain
.suf" -OperationMasterRole InfrastructureMaster

Move-ADDirectoryServerOperationMasterRole : Cannot find directory server with identity:"DC001.domain

Correct Syntax=
Move-ADDirectoryServerOperationMasterRole -Identity "DC001" -OperationMasterRole InfrastructureMaster

Monday, August 26, 2013

Screen Flickers when installing a Windows Server 2012 on Windows Server 2008 Hyper-V

When you install Windows Server 2012 on a Windows Server 2008 r2, you might see that the virtual machine is unresponsive and that the screen of the virtual machine is constantly flickering. This is caused usually because the virtual machine has not enough virtual memory configured. I have seen this issue occurring if the virtual machine has less ten 2048MB of memory assigned. Increasing the virtual machine's memory to more or equal to 2048MB resolves the issue.

Tuesday, June 25, 2013

Capital letters and Cisco RCC/Microsoft Lync

Yesterday i was working on a project that involves a new implementation of Lync 2013 and Cisco Cups.
We had enabled a user for RCC within Cisco and Lync, but the user was unable to register on the Cisco Cups Server.

The Cisco Cups is configured as a static route within Lync 2013, where it is used for a Cisco Sip domain called

We configured the user using the following settings:
LineUri = TEL:3567;phone-context=dialstring
LineServerUri = (where %UserName% is the Sam Account name of the user).

[Get-csuser "alfa" | Set-CsUser -RemoteCallControlTelephonyEnabled $True -LineUri "TEL:3567;phone-context=dialstring" -LineServerUri ""]

After enabling the user for RCC, we saw that the Lync client of the user was unable to register itself within the Cisco Cups Server to enable RCC. We enable logging on the Lync Server/client, where we saw that the registration was canceled by the Cisco Cups server. Where the Snooper reported "Call Leg does not exist".
 We could clearly see that Lync ad Cisco where communicating, but at a certain point Cisco Cups sends a Cancel to the client in which the Client ends the communication.

The reason for the Cancel is still unclear, so we retrieved the Logs from the Cisco Cups server. There we saw that the Cancel was send after giving an unspecified error on the dial string. We verified the dialstring within Lync again and confirmed that it was set correctly. As we had no real clue as what was going on, a colleague retyped the dialString within Lync, but receive the notification that nothing changed. 5 minutes later the configuration started working. Upon investigating what had changed, we saw that the colleague typed the following LuniUri:    tel:3567;phone-context=dialstring. He had specified regular letters instead if capitals for the TEL letters. To prove if this was indeed causing the issue, we enabled another account for RCC where we also specified TEL in capital letters. The user was unable to register in Cisco Cups, after changing the letters to regular, the user was able to register and use RCC.

By psoting this encounter, I hope to spare somebody's time in troubleshooting this issue..

Sunday, March 31, 2013

Beware of Exchange Web Services

I would like to point out that Exchange Web Services allows EWS clients to retrieve mail although Outlook Anywhere is disabled.
A customer of mine was not comfortable with Outlook Anywhere as an un-managed computer could be used to retrieve mail. So they wanted to delay the deployment of Outlook Anywhere until proper IPsec policies where in place. However we decided to publish EWS to allow Lync to retrieve Free/busy information for remote workers. To our surprise we discovered that Outlook mail was able to access his mailbox on Exchange 2010 although Outlook Anywhere was disabled.

Now there are a number of measurements you can take to prevent access although allowing EWS to be published externally. One option is to set the access to EWS by the mailbox features.
The can be done by using the Set-Casmailbox for the users. This is an "per user" approach in which you can allow some users and disallow some others.

You can also set it on the organizational level in which you allow or disallow it for the complete environment.
This is done via the Set-OrganizationConfig.

However both settings do not consider external and internal access. This means if you disable the setting then those client will also not be able to connect to EWS from a corporate or trusted network.


Tuesday, January 8, 2013

Securing POP and SMTP traffic from POP clients in Exchange 2010

I working on an exchange migration from Exchange 2003 to Exchange 2010. The customer is using a mixed environment with Microsoft Windows (Windows XP/Vista and Seven) clients, and Linux Unix clients which use POP and IMAP to retrieve mail from Exchange 2003. The Windows Clients use Outlook 2010, while the Linux clients use and a number of application which use IMAP or POP3 to access there mailboxes.

The customer wants to keep the IMAP/POP functionality in the new Exchange 2010 environment available, but wants to secure it where possible. In answer to that question i replied that we would keep the functionality, but switch to SSL encrypted communication between the clients and the servers. To do so, i also recommended that the clients would use the client submission port (TCP587(RFC5321)) in stead of simple SMTP (TCP25) to send to the server(s). Where we would also impose authentication. This way IMAP/POP and SMTP traffic would be encrypted and would only occur via authenticated users.
Enforcing the clients to use the client submission port enhances security as you would not need to create a relay receive connector for the clients on TCP port 25.

I knew this all is possible from theory but never implemented this before, as this is the first time i come across an environment where they still use IMAP/POP3 in a real live environment. To make sure i knew how to implement the theory i started playing in my test environment during the Christmas holidays.

In my test environment I have a single Exchange 2010 server with the three required roles installed (HUB/CAS/MBX), and downloaded and installed Mozilla Thunderbird as a POP client.

As we are going to use TLS to digitally encrypt the communications channels, we have to make sure that the intended FQDN's are present in the SSL certificate. The Exchange environment already has and SSL certificate assigned to it for SMTP and IIS, and we are going to reuse that SSL certificate to secure the POP3 access.
In the screenshot you will see that the hostname of the server is present in the certificate, and that is the FQDN we intend to use for POP and SMTP communication. Now we need to see, to which service the certificate is assigned.
Note: You can run previous commands in a single line by running "Get-ExchangeCertificate | fl CertifiacteDomains, Services"
In the screenshot you will see that the POP and Imap Service are already assigned in my case, this was because i toke the screenshots after testing and not while testing. To assign the Certificate to the IMAP/POP3 service, you need to run following command:
If you have multiple certificates in use:
List certificates:
 select the required certificate and assign it to the requested services
Get-ExchangeCertificate -Thumbprint "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | Enable-ExchangeCertificate -Services "POP, IMAP"
The required certificate is now assigned to the IMAP and POP3 service.
Note: If  the MSExchangePOP3 or MSExchangeIMAP where already started before assigning the certificate, you will need to restart these services. Is required each time you change or reassign a certificate to a service.
Configuring the Client Access Server
Open the Exchange Management Console, go to server configuration and Client Access Server Role.
Go to tab Bindings, and configure the IP addresses on which the Service should listen. By default it lists all IPv4 and IPv6 addresses, but I removed the IPv6 addresses as i do not use IPv6 in the test environment.

  Note: I still allow connection over port 110, but you can remove that if you wish to allow only secured communication (which will be done with my customer).     
Then go to the Authentication Tab, modify the authentication if required and verify that the certificate name is the name of the certificate which you selected in previous step.
Note: These are basically the default settings as Exchange 2010 aims to be secure by default.
  We do not need to modify the other tabs.

Now verify that the same settings apply to IMAP, which it should as it is designed to be secure by default.
Note: Modify the bindings if you wish to only allow secure connections.  
Starting the required services
The Imap and POP3 service are set to manual start in which they are not started automatically. If you wish to supply access by these services, you have to change the start-up mode to automatic. In my test environment i merely started the services as they are only required for testing the configuration.
To change the startup mode:
Get-service -name msexchangepop3, msexchangeimap4 | Set-Service -StartupType Automatic
Get-service -name msexchangepop3, msexchangeimap4 | Start-Service

Configure SMTP access (Client Submission Port)
We want user to authenticate and use TLS encryption when sending (relaying) mail through Exchange 2010.
Open the Exchange Management Console, go to server configuration and Hub Transport Server Role.

Select the receive connector for the client submission port which is called "Client" by defaul, but which i renamed to "Client Exch02". Right click and select Properties. Verify that the client network is allowed to use the connector in the Network Tab. Go to the Authentication Tab and select "Transport Layer Security (TLS)", "Basic Authentication" and "Offer Basic Authentication only after Starting TLS".
 Note: I have tried with TLS alone, but then the credentials are not accepted. I could only make with work with basic authentication, but that is no issue as the Authentication is done in a TLS encrypted tunnel in which the communication is encrypted anyways. This is why you need to make sure that "Offer Basic Authentication only after Starting TLS" is also selected.  
In the "Permission Groups" setting you have to make sure that "Exchange Users" and "Exchange Servers" is checked.

Client Configuration
As client i choose to use Mozilla Thunderbird, as it is a widely used client in Windows and operating Systems.
I am not going to completely explain the configuration of the client as it is pretty straight forward, yet i am showing the setting in the client to prove that communication is indeed TLS encrypted and authentication is required to send mail (SMTP).
POP3 Settings:
    SMTP Settings:
Here you see that authentication is required.
To client submission connector allows relaying for Exchange Authenticated users, so you have allowed relaying but on a more secure reliable way. If you have applications which need to send or relay SMTP traffic via your Exchange 2010 environment, you should investigate if the same settings can be used for these applications. 

Tuesday, November 13, 2012

Lync Monitoring: An error has occurred during report processing. (rsProcessingAborted)

You get following error when trying to view the "all incidents reports" in Lync reporting services:

“An error has occurred during report processing. (rsProcessingAborted) Query Execution Failed for Dataset “GetAll”. (rsErrorExecutingCommand) Error convirting data type nvarchar to Datatime.”  

The problem is caused by the language settings within Internet Explorer. More particular the date formatting that is used in different parts of the world. In my case Belgium/Europe we use the following formatting: dd/mm/yyyy while in the US the date format is mm/dd/yyyy. This date formating causes the report to fail, therefore following error is displayed:
"Error convirting data type nvarchar to Datatime."

In order to get the correct date formating which the report is expecting, you need to add the EN-US language to Internet Explorer: 

Open Internet explorer, Go to Internet Options, Appearance and select language.

Move En-US to first place and click ok.

Monday, October 1, 2012

Windows Server 2008 R2 Repair

I am having trouble with my test server which is running my virtual environment. It is running on hardware that is not really supported by Windows Server 2008 R2, and because of that the system sometimes reboots.
These reboots can cause virtual machines to become corrupt, if the reboot happens in a major write operation.

Now a week ago the server rebooted again unexpectedly and because of this my Lync Server would no longer boot up. I tried repairing the machine using SFC tool with the known syntax:
SFC /ScanNow /OffBootDir C: /OffWinDir C:\Windows

It can happen that following message appears:
"There is a Windows Repair pending which requires a reboot of the system"

If this message apears, you can revert the pending changes, or remove/rename the pending.xml file.

To revert the pending change, use following code:
dism.exe /image:C:\ /cleanup-image /revertpendingactions

Rename the pending.xml, which is found under C;\Windows\System32.

But after the reboot the system wouldn't boot. The next step would be to repair the Windows boot loader using StartRep.exe
Started the system in repair modus (CMD), where the systems start in X:\Windows\System32
type X\Resources\Recovery\StartRep.exe and press enter. The system asks you if you wish to repair the system boot loader, where you click Finnish. After clicking finish the system restarted perfectly into Windows, even all Lync services where started as intended.     

Installing Lync 2013 on Windows Server 2012

I wanted to install Lync 2013 on Windows Server 2012 in a test environment to get acquainted with the product. I downloaded the Windows Server virtual disk (VHD) from the Microsoft Website, booted up the disk and added it to my testdomain.

When provisioning your virtual machine, i would like to note that you need to provide at least 3072MB to the virtual machine, otherwise the installation of the front-end server will fail with following exclussion: "81" Is not a valid value for Configuration Option 'Max Server Memmory'. I started off with the Hyper-V default, which is 1024 which make the Lync role installation fail.

The first step is to install the Lync 2013 prerequisites. Unlike Windows Server 2008R2, we do not need to import the server module and use the add-WindowsFeature CMDlet, no In Windows Server 2012 you can kickof the installation of the prerequisites by using the Install-WindowsFeature CMDlet. The major of prerequisites are installed by following line:

install-WindowsFeature Web-Server Web-WebServer, web-Common-Http, Web-Default-Doc, Web-Dir-Browsing, Web-Http-Errors, Web-Static-Content, Web-Health, Web-Http-Logging, Web-Log-Libraries, Web-Http-Tracing, Web-Performance, Web-Stat-Compression, Web-Dyn-Compression, Web-Security, Web-Filtering, Web-Client-Auth, Web-Windows-Auth, Web-Mgmt-Tools, Web-Mgmt-Console, Web-Scripting-Tools, NET-Framework-45-Feature, NET-Framework-45-Core, NET-WCF-Services45, NET-WCF-TCP-PortSharing45, RSAT-AD-Tools, Windows-Identity-Foundation, Web-ISAPI-Ext, Web-ISAPI-Filter, Desktop-Experience, Server-Media-Foundation, web-asp-net, web-asp-net45

besides these prerequisites you also need to install the Web-Net-Ext (.Net extensibility 3.5), yet when you add Web-Net-Ext to the previous line you will see that the feature fails to install. This is because the sources for this feature have been stripped from Windows Server 2012. To add this feature you have to define the source in order to install it. These sources are not available on the VHD, so you will need to download the ISO itself. Once you have the iso you can find the sources under Sources\SXS\. My CD-rom drive on the server is Z, so I installed it with following line:
Install-WindowsFeature Web-Net-Ext -Source Z:\Sources\SXS\

# De Greyt Jurgen    #
# 15/11/2012    #
# Modified 8/11/2012            #
#Active Directory Remote administration tools
Add-WindowsFeature RSAT-ADDS

#Identity Framework
Add-windowsFeature Windows-Identity-Foundation

#Message Queying
Add-windowsFeature MSMQ-Server, MSMQ-Directory

Add-windowsFeature Web-Server, Web-Scripting-Tools, Web-Windows-Auth, Web-asp-net, Web-log-Libraries, web-http-tracing, web-stat-Compression, Web-Dyn-Compression, Web-Default-Doc, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-HTTP-Errors, Web-HTTP-Logging, Web-Net-Ext, Web-Client-Auth, Web-Filtering, Web-Mgmt-Console, Web-Asp-Net45, Web-Net-Ext45

#.Net Framework
Add-windowsFeature NET-WCF-HTTP-Activation45

Add-windowsFeature Server-Media-Foundation

Sunday, July 29, 2012

learning some new tricks

When configuring my network interfaces i usually use netsh to configure them. When being accustomed to using netsh it is pretty simple. To find the name of your interfaces you would use "netsh int ip show interfaces." To configure the ip addresses you would use the following syntax "Netsh Int Ip set address "local area connection" static 10. Adding DNS servers would be done with the following Synctax: Netsh int ip set dnsserver "Local Area Connection" static, adding a dns could be done by netsh int ip add dnsserver "Local Area Connection"

Now i was playing with Windows Server 2012, and wanted to challenge myself into configuring the interface through powershell. I guessed it was possible as I saw some NetIP commandlets in previous encounters. 

The first thing i did was trying to find the right cmdlets, the best to search them i used following synctax:
Get-Command "Set*NetIP*" 
This gave me a few hints to continue my search: In the same manner as with NETSH i need to find out the name of the interface i am willing to configure. Set-NetIpInterface, suggest that there would also exist an Get-NetIpInterface cmdlet. Putting my thinking into practice showed me the configured interfaces on the server.
 This showed that the interface we are trying to configure is called "Ethernet", the second cmdlet we where interested in was the Set-NetIPAddress cmdlet. Now we need to find out how we link the IpAddess that is specified in the Set-NetIpAddress is linked to the correct interface. To Find out i checked the help file of the Set-NetIpAddress: Get-Help "Set-NetIpaddress"
 This showed me the new-netipaddress cmdlet, which led me to the following string:
New-NetIpAddress -Ipaddress -DefaultGateway -InterfaceAlias Ethernet -AddressFamily IPv4 -PrefixLength 24
The new-NetIpAddress Cmdlet does not allow DNS or WINS to be set. Setting the DNS server would be done by the Set-DNSClientServerAddress cmdlet.
To set the DNS server we need to have the Interface Index number of the interface where we want to link the DNS servers settings to. The interface index number is shown by the Get-NetIpInterface cmdlet.
Setting the DNS Server is done with following Syntax:
Set-DNSClientServerAddress -Address IP First Server, IP Second Server -InterfaceIndex 'Indexnumber'

To Check your configuration afterwards you can use Get-netipconfiguration -InterfaceAlias Ethernet | fl
For all the netsh diehards, netsh still runs under Windows Server 2012.

Sunday, June 3, 2012

Certificates, certificates, all I see are certificates...

I was working on a Lync implementation for a local ISP. The design was set forward with one single site, which contains a Director, Front-end and edge pool, where each pool contains two servers for High Availability. After deploying the edge servers we noticed that the XDS replication was not occurring from the front-end servers to the Edge servers. We checked the Lync file share and the network to verify that the Front-end server could talk to the Edge servers on port 4443. Everything turned out OK, yet no matter what we did, the replication towards the edge servers didn't kick off.

While searching the internet for a possible solution, the following comment kept spinning in my mind:
"Replication issue's with the edge server are usually Network or certificate related." As we had checked the network, we started troubleshooting the certificates again. The certificates turned out OK, yet when investigating the certificates I did see that the Trusted Root Certificate store did contain a lot of certificates. I didn't count them, but usually you will see around 30 root certificates, the root CA container of the edge did contain so many certificates they didn't fit in a single view.

I started logging using the Lync Logging tool, yet this only gave the following warning: Master Directory not discovered yet. Investigated the eventlog where the following warning drew my attention in the system log:

Log Name:      System
Source:        Schannel
Event ID:      36885
Task Category: None
Level:         Warning
User:          SYSTEM
When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

I searched the Microsoft Forums where I found following thread:

We added the registry DWORD and replication kicked of perfectly.

Edit the registry on the Edge server to add a DWord value, SendTrustedIssuerList, to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key and assign it a value of 0. This will prevent schannell.dll from truncating the Root CA list from the edge server, and allow validation tests to pass.

More info on this registry setting can be found here:

This entry controls the flag controlling sending of list of trusted issuers. In the case of servers that trust hundreds of certificate authorities for client authentication, there are too many issuers for the server to be able to send them all to the client when requesting client authentication. In this situation, this registry key can be set, and instead of sending a partial list, Schannel will not send any to the client.
Not sending a list of trusted issuers might impact what the client sends when asked for a client certificate. For example, when Internet Explorer receives a request for client authentication, it only displays the client certificates that chain up to one of the certificate authorities that is sent by the server. If the server did not send a list, then Internet Explorer displays all of the client certificates that are installed on the client machine. This behaviour might be desirable, when PKI environments include cross certificates, the client and server certificates will not have the same Root CA and therefore, Internet Explorer cannot chose a certificate that chains up to on of the server’s CAs. By configuring the server to not send a trusted issuer list then Internet Explorer will send all its certificates.
This entry does not exist in the registry by default. This value is true by default.

A few days later we where testing the web conferencing and discovered that only anonymous users where able to join a conference. When a user selected domain user, in the web-interface following error would occur:

We enabled logging with the web-client and this showed us the following:

We applied the same registry setting to the Directors and front-end pool servers. After applying the settings user where able to join a conference using the Lync web client.



Monday, March 19, 2012

Multiple Exchange UM servers and microsoft Lync

A few weeks ago I was troubleshooting an issue with the Exchange 2010 UM auto attendant. When we called the attendant and asked to call a user within the organization the call would fail. 
This customer has two exchange UM servers, Node01 and Node02. We configured Exchange UM to use Lync as UM IP Gateway and everything worked well, except the Exchange UM attendant. When calling the attendant and asking the attendant to call a user, the call failed. We also saw the following event appearing  in the application eventlog:

Event ID: 1400 Source: MSExchange Unified MessagingThe following UM IP gateways did not respond as expected to a SIP OPTIONS request.
Transport = TLS, Address =, Port = 5061, Response Code = 0, Message = This operation has timed out.

1400 (Warning/MSExchange Unified Messaging) appearing regular in the event logs on the exchange UM servers, but didn't pay to much attention to it as everything was working (did only test the Exchange UM mailbox and not the Auto Attendant). Exchange has the Lync mediation server pool configured as UMIPGateway using a TLS communication. The TLS certificate that was placed on the Exchange for UM had following parameters configured: 
  • Common Name: UM.domain.local 
  • Subject Alternative Names: um.domain.local, Node01.domain.local, Node02.domain.local. 
I would like to express the fact that users where able to access their UM mailbox, and where able to retrieve or leave a spoken message in the UM mailbox using Lync (so here was TLS communication between Lync and Exchange).

In order to troubleshoot this, I increased the event logging level on the Exchange servers to expert level for Exchange UM and installed Wireshark to monitor the network traffic, and enabled logging on the Lync servers. Restarted testing with the Exchange UM attendant to call a Lync user. 

As expected the call failed. The application log on the exchange server and Lync logging didn't show any useful information, besides that the communication terminated unexpectedly. However the wireshark traces showed that only authentication traffic was passing between the two servers. Although the log did not explicit showed that authentication was falling i did presume that TLS authentication was failing as that was the only traffic between the two servers that was recorded. 

I inspected the Exchange Certificate over and over again, but to my knowledge nothing was wrong with the certificate. Spending hours searching the INTERNET I found two similar cases, one had the same event ID but was using OCS and had a wild card certificate which was not supported. The other one had a single UM server and he opened a call with Microsoft, troubleshooting with Microsoft pointed out that the problem occurred because the Subject name of his certificate was set to the external name of Exchange OWA.

At first I didn't pay much attention to the post, because i was still convinced that all PKI requirements where met. Up to that point I didn't pay that much attention to the common name value, and made sure that all the names that could be used in the communication with the server array is present in the Alternate Subject Names. The common name value was always set to the external name of the server array, which is according to Microsoft best practice:

As a best practice, you should minimize the number of certificates you use for your Client Access servers, reverse proxy servers, and transport servers (Edge and Hub). We recommend using a single certificate for all of these service endpoints in each datacenter. This approach minimizes the number of certificates that are needed, which reduces both cost and complexity for the solution.


Running out of Idea's I decided to change the Unified Messaging certificate to match the common name to the FQDN of the server on one server. Stopped the MSexchangeUM service on the other to make sure that the one would be used that had the new certificate. Resumed testing, to my surprise the attendant is now able to call users through Lync.

Surprised by this outcome, made me wonder and doubt everything I knew from PKI so far. As with every issue I encounter, I will always try to explain that issue to myself in which I can explain why the issue occurred and what I can do to prevent it.

Been deploying Exchange for many years now, and never ran into any issue's regarding PKI, and this encounter shacked my world. It seemed that the way I was deploying Exchange Certificates had a flaw But if it has a flaw, how come I never ran into any similar issue's before?      
Have to admit that I haven't deployed a lot UM server roles, as many enterprise already have an existing solution. But surely did a fair share of Exchange deployments with multiple Hub/Cas servers and never ran into issue concerning certificates.  

Maybe there was nothing wrong with the certificate in which the common name of the array can still be used if I change the UM server name by using the Set-UMServer cmdlet. The UM server was still pointing to each server individually. But if changing the UM server to represent the name of the array, will we loose high availability? As in when Round robin is used, clients are pointed to servers that may or may not be on-line...

What about manageability? If the common name has to be the FQDN of the server, you would need to run a certificate request on each server, and each server will have its own private key. But If you use one common certificate for all, you would need to change the certificate on all servers if you wish them to use the same private key.

Is there an advantage of using a singe shared private key among all your servers? Hmmm, not sure. In case of Exchange UM surely not, as it is real-time, and in case of fail-over the session would always be lost. But what in other commodities (SMTP, HTTPS, RPC/MAPI)? No, I don't think so. Even if you have hardware load-balancers in place, a new session will be created when a fail over occurs.

The more I keep pondering about the subject, the more questions arise in my mind.  



Sunday, March 18, 2012

Windows Server 8 - DCPromo? Install domain Controller using the Command Line.

I am playing around with Windows Server 8, and wanted to setup a first domain controller for the Windows Server 8 test domain. Since I like the command-line, I configured the Ip address using the netsh cmdlet and changed the computer name using netdom. After the reboot, I reopened Powershell and ran "DcPromo", which gave me following answer:
  Darn, did DCpromo get removed? No, I not want to use the server manager, I want to use the command line tools ;). Lets try CMD.
Doh, what about powershell cmdlets?
First we Import the server manager to check the availability of Active Directory services:
Import-Module Servermanager
The feature we where looking for is the "AD-Domain-Services"
Add the feature using the Add-WindowsFeature CmdLet
Add-Windowsfeature AD-Domain-Services
Once the feature is installed you get access to a new powershell module. You can always check the installed modules by using the Get-Module CmdLet.
The new commandlet that is available is the ADDSDeployment. Import the new module:
Import-Module ADDSDeployment
No we are finally ready to install the Active Directory roles:
I used following command for setting up my Windows Server 8 test forest/domain
Install-ADDSForest -CreateDNSDelegation:$False -DataBasePath:C:\NTDS\ADDSDB -ForestMode Win8 -DomainName W8Test.local -DomainMode Win8 -DomainNetBiosName W8Test -InstallDNS:$True -LogPath C:\NTDS\Log -SysvolPath C:\NTDS\Sysvol -RebootOnCompletion:$True
You can also add the -Force parameter if you do not want to be promted.

 On completion the server will reboot, in which we have deployed our first Windows Server 8 domain Controller in our new Windows Server 8 Forest and domain.


Wednesday, March 14, 2012

Bus Crash Switzerland

Last night a terrible accident happened in a Swiss tunnel, tacking the lives of 28 people of which 22 children. As a father of 3 I would to express my deepest condolences with the ones who are left behind.

Monday, February 20, 2012

Decommission Lync 2010 standard pool

A lot of companies start with a Lync standard edition in a POC, when the POC is approved they upgrade their standard pool to an enterprise pool. You cannot upgrade you existing standard pool to an enterprise pool, but have to create a new enterprise pool, which I did.

Firstly a bit of explanation about the Prove Of Concept. The network with this customer are basically islands where only a limited number of ports are opened between these networks. This has as a result that if two users, each located on a different network try to communicate with each other. As the client ports are blocked they need to use an edge server's MCU to successfully communicate with each other. So in the POC two servers where deployed, a Single edge and a single Standard front-end server/pool.
The POC was deployed in the production environment where Exchange UM plus multiple application where integrated as trusted applications in Lync. also a PBX gateway ad voice route was defined.

As this is a production environment, with real live user accounts it seemed best the deploy the new environment along side to the existing POC deployment. After the new deployment was in place the users where migrated to the new pool.

Get-csuser | where {$_.registrarpool -like ""} | Move-CsUser -Target

The following step is to move the conferencing directory to the now pool:

Get-CsConferenceDirectory | where {$_.RegistrarPool -like ""} | Move-CsConferenceDirectory -Target

As Exchange UM was set up, we needed to move the Exchange Um Contact.

Get-ExUmContact | Move-ExUMContact -Target

Then launched the Lync Topology builder.
Removed the association of the front-end pool with the edge pool.
Removed the PSTN gateway
removed the voice route
Get-CsVoiceRoute | Remove-CsVoiceRoute

Removed the trusted application servers.
Removed the edge Server
Published the topology and ran the deployment wizard on all the servers to update their configuration.

Checked and moved remaining application end-points
Get-CSApplicationEndPoint | where {$_.Registrarpool -like ""} | Move-CSApplicationEndPoint -Target

Opened the topology builder again. Removed the Standard edition front-end pool and published the topology. Be sure to wait for replication between all the different step, advancing to fast can result in temporary errors.


Sunday, February 19, 2012

Powershell Get service status compared to stratup type.

I like using command type tools, in stead of the GUI. One of my favourites is surely Powershell. Now what I find disappointing is that you cannot get the start-up type of a service using the get-service cmdlet. The only way to get the startup type and compare it to its current status is using WMI.

Following comandlet lists of service where the startup type is set to automatic but where the current status is stopped.  

Get-WmiObject -Class Win32_Service -Filter "StartMode='Auto' AND State='Stopped'" | sort DisplayName | Format-Table DisplayName, StartMode, State

Monday, December 5, 2011

Exchange 2010 SP2 released

It seems that Microsoft released Exchange 2010 SP2 about 10 hours ago. You can get it here:

Wednesday, October 26, 2011

Oh Certificate where art thou

A few days back i had to replace the external certificate on an edge server with a new third party certificate. I created a new certificate request (with private key) and mailed it to the guy who was responsible for requesting the certificate with VeriSign. Moments later i received my SAN certificate.

I logged on to the edge server and opened the Lync Deployment Wizard to import the certificate using the GUI. I select import new certificate and browsed to the path where i placed the certificate. Clicked import, and verified that the command completed successfully.

In the same window I now ran the assign new certificate wizard, to assign the newly imported certificate to the external interface of the edge server. To my surprise I could only select one of the old certificates. The newly imported certificate could not be seen.

I wondered if something went wrong during the import, so I opened the local computer certificate store. Well nothing wrong to see here, the certificate is nicely imported in the local personnel certificate store of the computer. Clicked the Refresh button in  the deployment wizard, ran the assign new certificate again, but still no luck.

Damn, what is going on here? Ghost in the machine? You know what, i will start all over again. So  removed the certificate from the local certificate store. Opened the deployment wizard, imported the certificate using the wizard. Again the wizard told me the certificate imported successfully. But the greater was my disappointment, when i discovered that the certificate was still not present.

Ok, had it using the GUI, will use Powershell this time, that will always work. Imported the certificate using powershell, and tried to assign. No, still no certificate available. Ok, this is really the Ghost in the machine, you know those days when you cant seem to achieve anything.

Tried all over again, but this time i checked the html files which are created in the temp folder by lync (%userprofile%\appdate\local\Microsoft\temp). Although the wizard reported that the command completed successfully, I could see that the certificate was not imported. As reason the log file logged the following: Certificate already present or could not process the private key.

Opened the local computer certificate store, and now saw something fishy. The old certificate, which was generated by the internal CA, had a key displayed in the icon for the certificate. The new certificate, although present did not display that key. The picture below displays a certificate which has a valid private key.

That convinced me that there was something wrong with the private key of the certificate. I have seen this situation in Exchange, and has been widely documented on the internet, but never saw it in Lync before. Nevertheless we are talking about certificates no matter where they are applied to. So this made me decide to use the same sollution, which is repairing the certificate using Certutil.

Opened the certificate, clicked the Details tab and copied the serial number of the certificate.

 Then opened a dos-box in administrative mode, where i used following command:
Certutil -repairstore my "xx xx xx xx xx xx xx" (where x is the serial number of the certificate).
Which gave me following result:
Open the deployment wizard and could successfully assign the certificate this time. You see experience comes in handy ;) !

Discovered a bit later that the friendly name was missing from the certificate when i opened the certificate wizard (Deployment Wizard). You can also assign a friendly name to the certificate using certutil.

Required steps:
First you need to create a inf file that contains the friendly name you wish to assign to the certificate. Open notepad and insert following text:

Signature = "$Windows NT$"
11 = "{text}Friendly Name

Adjust Friendly Name to the friendly name you wish to assign to your certificate. Save the notepad as an INF file in certain directory. I used C:\Temp\FriendlyName.inf.

Second, open the command prompt in administrative mode, and type following command:
Certutil -repairstore my "xx xx xx xx xx xx xx" (where x is the serial number of the certificate) C:\Temp\FriendlyName.inf

Reassign the certificate in the certificate wizard and you will see that the certificate now displays the friendly name you have defined in the inf file.


Monday, October 17, 2011

Lync Location Policy

This is the second article in the article series about policies in Lync 2010. The policies we are going to discuss are the location policies. The whole idea and wherefore it is designed is to provide an indication of where the user is located when calling 911. The E.911 solution has been in place for many years for hard phones, but soft phones or IP phones where not covered by the traditional E.911 system.

Enhanced 911, E-911 or E911 in North America is one example of the modern evolution of telecommunications based system meant as an easy way to link people experiencing an emergency with the public resources that can help. The dial-three-digits concept first originated in the United Kingdom in 1937. It has spread to continents and countries across the globe. Today other easy dial codes including the 112 that was adopted by the European Union in 1991 and others like it have been deployed to provide free-of-charge calling to those who need help during emergencies. The Emergency telephone number article contains comprehensive information regarding other emergency dialing codes for countries outside North America. (Source:

In Lync 2010 Microsoft incorporated a location mechanism to provide location awareness for Llync clients and Lync client phones.

I not going going to blog about the complete E.911 implementation on Lync, because this has already been done numerous time on other blogs, and there is no point in reinvented hot water over and over again. The most complete article i have ever read on the subject, is an article from Mark King which you can find on following location:
It gives a thorough understanding of what E.911 is in Lync and how to implement it.

What we will be focusing on is the policies that come with the E.911 implementation in Lync. One thing i do need to point out is that the Enhanced 911 implementation is only supported in North America. For the rest of the world you can configure it, but there are no agencies that verify the location, so all location are unverified.

Which brings us to custom, suggested and validated locations.

Custom locations are when you allow the users to configure there own location in the client. This information is stored in the PersonalLisDB.cashe file, which is located in the user profile on the computer. When the computer recognizes the location of the user, it will reuse the information stored in the local LIS db. The location is recognized on the Mac address of the default gateway. The locale database can store up to 10 locations.

Suggested locations are locations that have been set by the Location Information Service database stored on the Lync Back-end server. This database is build up by the Lync administrators where he/she defines certain parameters required to build location awareness. These parameters are:
  • Subnets
  • Switches
  • SwitchPorts
  • Wireless access points
So to recap, a suggested location is a location that has been derived from the information stored in the central Location Information Service database stored on the Lync Back-end infrastructure, which has not been validated by an organization that validates and represents Master Street Address Guide.

Validated locations are locations that have been derived from the location parameters stored in the LIS database on the Lync Back-end infrastructure. The location is verified and validated by MSAG, but as noted before is only supported in North America.

Note: Europe will probably be working on a similar solution for the near future.

Central Database:
The location information is stored in location database which is called LIS.mdf on the Lync back-end server.

When we search for location in the Lync Management Shell, we get following result:
Get-command "*Location*"
CommandType     Name                            Definition
-----------     ----                            ----------
Cmdlet          Get-CsConfigurationStoreLoca... Get-CsConfigurationStoreLoca...
Cmdlet          Get-CsLisLocation               Get-CsLisLocation [-Unrefere...
Cmdlet          Get-CsLocationPolicy            Get-CsLocationPolicy [[-Iden...
Cmdlet          Get-Location                    Get-Location [-PSProvider Cmdlet          Grant-CsLocationPolicy          Grant-CsLocationPolicy [-Ide...
Cmdlet          New-CsLocationPolicy            New-CsLocationPolicy [-Ident...
Cmdlet          Pop-Location                    Pop-Location [-PassThru] [-S...
Cmdlet          Push-Location                   Push-Location [[-Path] Cmdlet          Remove-CsConfigurationStoreL... Remove-CsConfigurationStoreL...
Cmdlet          Remove-CsLisLocation            Remove-CsLisLocation -Locati...
Cmdlet          Remove-CsLocationPolicy         Remove-CsLocationPolicy [-Id...
Cmdlet          Set-CsConfigurationStoreLoca... Set-CsConfigurationStoreLoca...
Cmdlet          Set-CsLisLocation               Set-CsLisLocation -Location ...
Cmdlet          Set-CsLocationPolicy            Set-CsLocationPolicy [[-Iden...
Cmdlet          Set-Location                    Set-Location [[-Path] Cmdlet          Test-CsLocationPolicy           Test-CsLocationPolicy [-Targ...

We will not be explaining every setting, because we will have to write a short book, which information is already available on the Microsoft website. We will be focusing the Set-CSLocationPolicy and the Get-CSLoactionpolicy. There is no reason to explain both cmdlets as get-CsLocationPolicy gets the location policy and Set-CSLocationPolicy set the parameters for the location policy.

Gets all location policies, as you know Lync policies are in-band provisioned and can be applied to following scopes:
  • Global
  • Site
  • Tag (User/Service/Pool)
We have a location policy which is called LocTest, which we will discuss here.

Identity [mandatory = Name of the location policy)                         : Tag:Loctest

Description (optional = description of the location policy)                     :

EnhancedEmergencyServicesEnabled (Mandatory = specifies whenever E911 is enabled)  : False
Only supported in North America.

LocationRequired (Mandatory = Specifies if location needs to be set)                 : no
Options are Yes, No and Disclaimer
  • Yes: When LocationRequired is set to Yes, the set your location will turn up Red in the Lync client. Location is required but can be ignored.
  • No: Location is not required. The user will not be prompted for a location, but can still be set if the user does so.
  • Disclaimer: The user sees that the location is marked red, prompting the user to set a location, if the user removes the prompt without setting the location, the user will receive a disclaimer. The disclaimer has to be set using the Set-CsEnhancedEmergancyServiceDisclaimer.

UseLocationForE911Only (Mandatory =   Location information can be used by the Microsoft Lync 2010 client for various reasons (such as notifying teammates of current location). Set this value to True to ensure location information is available only for use with an emergency call.)         : False

PstnUsage (Optional =
The public switched telephone network (PSTN) usage that will be used to determine which voice route will be used to route 911 calls from clients using this profile.)   :

EmergencyDialString (Optional = The number that is dialed to reach emergency services. For example 911, 112, 100) :

EmergencyDialMask (Optional = The number entered here is translated to the value in EmergencyDialString. Example: if you enter 112 here and enter 100 in the EmergencyDialString, 112 will be translated to 100) :

NotificationUri (Optional: One or more SIP Uniform Resource Identifiers (URIs) to be notified when an emergency call is made. For example, the company security office could be notified through an instant message whenever an emergency call is made.) :

ConferenceUri (Optional: The SIP Uniform Resource Identifier (URI), in this case the telephone number, of a third party that will be conferenced in to any emergency calls that are made. For example, the company security office could receive a call when an emergency call is made and listen in or participate in that call (depending on the value of the ConferenceMode property). :

ConferenceMode (Optional:
If a value is specified for the ConferenceUri parameter, the ConferenceMode parameter determines whether a third party can participate in the call or can only listen in. Available values are:
- oneway: Third party can only listen to the conversation between the caller and the Public Safety Answering Point (PSAP) operator.
- twoway: Third party can listen in and participate in the call between the caller and the PSAP operator.) :

The location policy cannot be set or changed by the user if LIS information is provided by the location database. To retrieve the information that is used for LIS, use following CMDLet: Get-CsNetworkConfiguration.

Friday, September 30, 2011

Lync 2010 Policies and settings

It is pretty obvious that Lync is a very complicated product, that aligns with many features in a corporate network. For example, Lync integrates or provides telephone, provides numerous forms of collaboration and presence.
We are not going to talk about the various features in Lync, Which have been widely discussed on other blogs. But lets talk about the numerous policies and configurations that help you manage this product. We clearly put the focus on policies, and add the configuration as a bonus, as many settings link to configuration settings.

When talking about policies we have following policy scopes in mind:
  1. Client Policies
  2. Location Policies
  3. Voice Policies
  4. Conferencing Policies
  5. Presence Policies
  6. Archiving Policies
  7. Pin Policies
  8. External Access Policies
  9. Hosted Voice Mail Policies
  10. Client Version Policies
Each scope will be discussed as a separate article.

1. Client Policies

We start off by discussing client policies.
Client policies apply to the Lync client as the name suggests. But before starting to describe what can be applied using client policies, it is interesting to look at how policies are applied in Lync 2010.

When talking about client policies, we have to make an distinction between two types of policies. Namely the "Out-of-band provisioning" policies and the "In-band provisioning" policies.

1.1 Precedence
As we are talking about client settings, the settings can be applied at several levels. The settings can be done by tattooing the registry, group policies, Lync policies, or configuring the options by hand in the client. It is important to understand which setting takes precedence when being set.

The precedence is set from 1 to 4, in which 1 takes precedence over 2, 3, and 4.
  1. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator 
  2. HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
  3. Lync Server In-brand provisioning
  4. Lync Option Dialog box
Note: Another important thing to say is that lync allows policies to be set at certain levels, an example of this is the client policy and the voice policy. The voice policy will overrule the client policy if the user is voice enabled. An example is delegations in outlook when scheduling an on-line meeting. If you want your users to be able to schedule a online meeting you have to set the client policy to EnableExchangeDelegateSync to true. However if the user who has delegated his calendar is voice enabled, we have to make sure that "DelegationEnabled" is set to true in the voice policy for that user. If the voice policy for that user still states "DelegationEnabled: False", delegates will be unable to schedule an online meeting for the voice enabled user.

1.2  "Out-of-band provisioning" policies
"Out-of-band provisioning" or group policies have been replaced by "In-Band provisioning" policies. Out-of-band provisioning" policies are applied using group policy, and therefore have the limitation that come with group policies. "In-Band provisioning" do not use group policies and therefore do not have the limitations of group policies. Does this mean that group policies are gone? No, they are not, Goup Policies can still be used, and are applied to the client before the client logs on the Lync infrastructure.

These policies are available as a ADM file which is part of the Lync 2010 client download from the partner website. This communicator.adm file can be imported in any group policy template and applied to a computer, set of computers, user or off course a set of users.

The communicator.adm file contains 15 policy settings:
  1. Specify Transport and server: Allows you to specify the name of your front-end and edge server. This way you do not need to provide the DNS names required for client Autodiscovery on the WAN or LAN.
  2. Enable Strict DNS naming for server name: When not set, or disabled the client will connect to the SIP server that has the domain name of the SIP address. Meaning that if your SIP address is, the sip server should be If you enable this setting, the client will communicate with whatever server that has the SIP domain configured. In case the policy is enabled the client could communicate with a server called, in which you would allow a potential risk for spoofers to mimic the sip server. Does only apply when TLS is used (default).
  3. Configure SIP security mode: If you enable this policy the client requires TLS to be used, in which the client will not fall back to TCP in case TLS cannot be used. This setting if enabled also requires the client to authenticate using Kerberos or NTLM. If this setting is enabled all communications must run through the SIP server, in which peer 2 peer communications are disabled.
  4. Configure SIP compression mode: whether or not to use SIP compression. By default the network adapter speed specifies whether compression is or is not used. Enabling this setting could increase logon time.  
  5. Prevent users from running Microsoft Lync: States whether or not the lync client can be used by that particular user or machine.
  6. Allow storage of user password: If you enable this policy setting, Microsoft Lync can store a password on request from the user. If you disable this policy setting, Microsoft Lync cannot store a password. If you do not configure this policy setting and the user logs on to a domain, Microsoft Lync does not store the password. If you do not configure this policy setting and the user does not log on to a domain (for example, if the user logs on to a workgroup), Microsoft Lync can store the password.
  7. Require logon credentials: Requires the user to provide logon credentials for Microsoft Lync rather than automatically using the Windows credentials when Microsoft Lync authenticates the user using NTLM or Kerberos. If you enable this policy setting, Microsoft Lync requires the user to provide logon credentials. If you disable or do not configure this policy setting, Microsoft Lync authenticates the user based on the logon credentials for Windows.
  8. Disable HTTP fallback for SIP connection: Prevents from HTTP being used for SIP connection in case TLS or TCP fail.
  9. Disable version Server check: Prevents Microsoft Lync from checking the server version before signing in.
  10. Additional Server version support: Specify a semicolon separated list of server version names,
    e.g. RTC/2.8;RTC/2.9, to which Microsoft Lync allows logon in addition to the server versions that are supported by default. Space character is treated as part of the version string.
  11. Enable using BITS to download address book service files: This policy allows Microsoft Lync to use BITS (Background Intelligent Transfer Service) to download the Address Book Services files.
  12. Use compact DELTA file for GAL: This policy allows Microsoft Lync to use compact delta file for GAL.
  13. Help menu: This policy is used to extend the Help Menu in Microsoft Lync. An administrator can specify a help web site for Microsoft Lync using these keys. Help Menu Text is a string value that specifies the text to display to the user in the Help Menu for the help web site. Help Menu URL is a string value that specifies which web site to open when the user selects the Help Menu Text item in the Help Menu. Note that both Help Menu Text and Help Menu URL need to be specified in order for the Help Menu item to appear in Microsoft Lync.
  14. Launch Microsoft Link First Run: This policy defines the behavior of the Microsoft Lync First Run. Whether it's enabled or not, whether it should be launched automatically or not.
  15. Turn on tracing for Lync: Turn on tracing for Lync, primarily for use to assist customer problem solving. If this policy is not configured, then the user can specify the choice in Lync options. Otherwise, the corresponding behavior is enforced and the user has no choice.
Note: policy 1, 2, 3, 5, 6, and 7 can be configured on both the user as the computer level of the policy. Yet the computer policy takes precedence over the user policy. All other policies only apply on the computer level of the policy.

Now explaining how group policies work and how they are applied is really not the scope of this article. Yet i do want to point out why group policies have a certain disadvantage, and why Microsoft moved away from group policies and implemented the new way of assigning policies (in-band provisioning). Group policies are typically applied at logon, and are refreshed every 90 to 120 minutes by default (90+ random offset of 30 minutes). So when applying new settings this setting are not automatically applied, unless the policies are refreshed manually on the client. A second disadvantage is that you are not really sure that the policies set are actually applied. It could be that a corporate user who logs on to the network using VPN, does not get his/her policies applied, due to slow link detection. Or that the remote user logs on to the network using a computer that has not been subjected to group policies (home computer, none Windows system). 

1.3 In-band provisioning
Microsoft acknowledged the problem with group policies, and developed a new way of assigning policies in Lync 2010. The new way is known as in-band provisioning. The policies are applied through Lync itself and the policies are stored in the Lync CMS store and replicated to the local copy of the database.

The policies are applied as soon as replication has been done, and the policy is assigned to a certain level. The levels to which a policy can be applied is Global, Site, and Tag.
  1. Global: The global Lync infrastructure, in this case every lync client.
  2. Site: A Lync site, every client within a Lync site. The Lync organization can have multiple Lync Sites. 
  3. Tag: the tag can be a user, group or service.
The client policy can only be set by using the Lync Management Shell and not by the Lync Control Panel. Most of the settings that determine Microsoft Lync 2010 features and functionality are configurable through Microsoft Lync Server 2010 Control Panel. However, there are several essential policies and settings that significantly impact client functionality and that can be configured only by using Group Policy or Lync Server Management Shell.

The following CMDlets are used to manage the client policies:
  • Get-CsClientPolicy: Get the client policies which are configured, if you do not specify a name all client policies are returned.
  • Grant-CsClientPolicy: Assigns the policy to a level (Global, Site, Tag). If you do not specify an identity the client policy is applied Global.
  • New-CsClientPolicy: Creates a new client policy. Among other things, client policies help determine the features of Microsoft Lync 2010 that are made available to users; for example, you might give some users the right to transfer files while denying this right to other users.
  • Remove-CsClientPolicy: Removes an existing client policy. Among other things, client policies help determine the features of Microsoft Lync 2010 that are available to users; for example, you might give some users the right to transfer files while denying this right to other users.
  • Set-CsClientPolicy: Modifies the property values of an existing client policy. Among other things, client policies help determine the features of Microsoft Lync 2010 that are available to users; for example, you might give some users the right to transfer files while denying this right to other users.
  • New-CsClientPolicyEntry: Allows you to assign new options to the client policy.

Information on the settings and applying the policy can be found here: