Changing the Lync 2013 or Skype for Business contact card

The contact card is a shared component of Office 2013 – everything that can display a contact uses the same setttings. The fields you see will change depending on whether information is populated for them, either in Active Directory or a contact you’ve created for them in Outlook. Here’s an example:

contactcard

A requirement on a recent project was to have extra information displayed in the Lync contact card. For staff who have an assistant, their Active Directory account is populated with the assistant’s name and telephone number (in the msExchAssistantName and telephoneAssistant attributes), and this is useful to see at a glance within Lync, as they may be the best route to get in contact.

Microsoft publish information about customizing contact cards via registry keys on TechNet, which we tried, and couldn’t get it to work. Instead we went down the route of customizing Office 2013 via the official Group Policy templates.

Download the Office 2013 Administrative Template files

If you’ve not made any changes to Office 2013, you may not have these installed. Download the package then extract the files. Included is a handy reference in Excel form which tells you what each setting does and the registry key it sets.

You can either copy the contents of the “admx” folder to C:\Windows\PolicyDefinitions on the computer that will run the Group Policy management tools, or to the \policies\PolicyDefinitions\ folder on the SYSVOL for the domain.

Create a test GPO and make some changes

Open up Group Policy Management, and under Group Policy Objects, create a new GPO for testing. Right-click it and select Edit.

Contact Card settings are under User Configuration > Policies > Administrative Templates > Microsoft Office 2013 > Contact Card > Contact Tab.
gpo1

If you refer to the helper text or the Excel reference sheet, it shows the line number for each piece of information – generally they go from most to least commonly used. In our case, we needed everything up to “Company” (12th line), which left line 13 and 14 to be replaced with new information.

gpo2Line 13 is “Work Address”, so we went into the “Replace AD – Work Address” setting and put in the AD attribute that we want to use to populate the field – msExchAssistantName in our case.

gpo3

We also need to change the corresponding label on the contact card so that it displays something appropriate for the new info. The “Replace Label – Work Address” setting was changed to “Alternate Contact”.

This was repeated for line 14 (Home Address), for display of the assistant’s telephone number. There isn’t a documented limit for label names, but tried to keep this at a similar length to others so used “Alt Contact Number” as a label.

These line numbers are also used if instead of a GPO, you prefer to set registry keys via some other method:

reg1

Test and verify

To try out the changes, either apply the GPO to a test machine/user or set the registry keys manually. All Office 2013 application will have to be closed and restarted to see the changes.

Success! We now have a contact card displaying the name and telephone number of the assistant.
final

Limitations and considerations

There’s a few things I’ve found from playing around with the contact card:

Extra phone numbers (such as in this example) often can’t be clicked to dial – they display as simple text.

The contact card comprises the Calendar information (which can be turned on or off) then 16 items of information, with no possibility to add more than this. You are always replacing a (hopefully unused or unimportant) field with another. It’s possible that what is unused by some users is considered important by others.

Information is always shown in line order – so if you replace “Home Phone” (line 6) it will always appear before “Office” (line 11). You may need to move the default ones to a different line to get the order you want.

Since I did this work, the Skype for Business client was released. I’m happy to confirm that as this uses the same Office 2013 contact card, the changes work the same regardless of whether you use the Lync 2013 UI or the Skype for Business UI.

 

Multiple Lync Persistent Chat pool headaches

Why would you want more than one Persistent Chat pool? We can scale a single pool to 4 active servers each with 20,000 users, to support 80,000 concurrent PChat users – enough for a great many organizations. In many cases, a single central PChat pool makes a lot of sense. With good use of PChat categories, different groups of users can be separated if needed, and administration (such as creating new rooms) easily delegated.

However, this single-pool model doesn’t fit all. Sometimes different regions or countries host their own Lync infrastructure in a shared topology and each will need (or want) their own Persistent Chat pool.

Generally, this works fine but there’s a problem – the dreaded “Your chat room access may be limited due to an outage” message. You may have seen it before if you’ve broken something, but you will also see it if any PChat pool defined in the topology is down.

pchat-outage

Your local PChat pool may be up, users may be able to get to their chat rooms, but this can still cause a lot of helpdesk calls. It also looks very similar at a glance to the “Limited functionality” warning, which can impact users’ perception of how reliable Lync is.

There are some practical things you can do to help mitigate this however:

  • Agree patching / outage windows for Persistent Chat pools, to avoid users’ typical working hours (in all regions!)
  • Care and planning are needed when adding a Persistent Chat pool. Ensure at least one server for the new pools is ready to be installed and configured as quickly as possible, and perform this out of hours.
  • Educate users about the message, and what it really means – it’s warning of an outage, but it may not be an outage on their pool!
  • Consider limiting the number of users enabled for Persistent Chat – if only 10% of users need it, they’re the only ones who should be enabled. Others won’t see the “outage” warning if they’re not enabled for PChat in the first place.
  • Consider limiting the number of PChat pools in the organization. While you can collocate PChat on a Standard Edition server, this only makes sense in small environments. Don’t let the failure of a single server for 100 users cause an outage warning for 100,000+ users!

Hopefully some better logic around this warning will come in future versions of the Lync (or Skype for Business) client. In the meantime, think carefully about whether you want multiple PChat pools and if you do, what you need to do to avoid the dreaded “outage” message!

Controlling Lync 2013 Mobile Clients Via Policy

Lync 2010 had a very limited set of options for controlling the use of mobile clients. This has been extended in Lync 2013 and it is worth reviewing before deploying. The defaults are generally sensible but may be too “free” in some environments. You may find that a single policy works for all users, or some may have specific needs or regulations that apply that require a special policy.

Beyond the global policy, new policies can be created for sites or users.  As with all Lync policies, these are not cumulative – only a single policy applies to a particular site or user and all of the settings within it are the ones to be used.

While you can create a mobility policy in the Lync Server Control Panel, this won’t expose all of the settings. Using the New-CsMobilityPolicy or Set-CsMobilityPolicy cmdlets is a better bet.

Basics

EnableMobility

The best place to start – if set to True, users can sign in and use Lync mobile. If set to False, they are prevented from doing so.

EnableIPAudioVideo

When set to True, users can make and receive VOIP audio and video calls using the mobile client. When set to False, it will behave much like the 2010 mobile client – IM & presence and calls made via OutsideVoice / Call via Work (explained below) if allowed.

Telephony – Call Via Work

EnableOutsideVoice

This is probably the most misunderstood setting, and one of the few that also existed in Lync 2010. It is set to True by default.

The other name for this functionality is “Call via work”. As the Lync 2010 mobile client did not have the ability to make a VoIP call, this was the workaround and is still useful in many situations now.

If the user tries to make a call but doesn’t have a method to do it via VoIP (eg. they have RequireWifiForIPAudio enabled and are on 3G), Lync Server will establish a call to their mobile telephone number – this goes via the PSTN, not Lync. The user picks up the call, and Lync Server makes another call to the number or contact they were trying. Once established, Lync Server joins the two calls together and they can start the conversation.

call via work 2

When is this useful? Really any time that network conditions mean a PSTN call would be better.

  • Your work (Lync) number is presented to the other party, instead of your mobile
  • Unless you pay for incoming calls, there is no cost to the user – good in BYOD scenarios
  • This also works with any Lync contacts, including those not enabled for Enterprise Voice, or federated contacts who you may not have a number for!
  • You will be on the move during the call – a VoIP call cannot be handed off between wifi and 3G.

This requires the mobile client to be capable of receiving a phone call – so most tablets such as iPads will not work for this. The user also needs a voice policy that is enabled for simultaneous ring, and is allowed to call their mobile number as well as the number they’re calling.

Concerns around this feature are normally driven by cost. A call made this way involves two PSTN calls from Lync – one to the user’s mobile phone, one to the number they’re contacting. In Europe at least, mobile phone contracts tend to have generous allowances, so companies would rather force staff to make a mobile call if necessary instead of using this Lync feature. It is worth piloting and seeing if the functionality is worth the extra cost for your organization.

If set to False, and a call is attempted that can’t be made via VoIP, the Lync client will pass the number to the phone’s dialler to make the call instead.

Connectivity

Within the mobile clients, the user has options to force use of Wifi for different types of call. They may not want to use up their mobile data allowance, or may want to ensure that wifi is used for best quality.

The administrator can override these settings and prevent the user from changing them via the following:

RequireWifiForIPAudio

RequireWifiForIPVideo

RequireWifiForSharing

They are all set to False by default (user can decide). If set to True, the options are still seen but the sliders are greyed out.

Note that a video call is actually an audio and video call – if RequireWifiForIPAudio is true and RequireWifiForIPVideo is false, then video calling over 3G will not work!

In this example, RequireWifiForIPVideo  is set to True and the others set to False:

setting1

AllowExchangeConnectivity

For connection into the user’s Exchange mailbox, to retrieve voicemail and show the meetings for today and tomorrow, the client uses Exchange autodiscover to find the Exchange Web Services (EWS) address. The default  value is True, which will allow this to be attempted and will display the information if successful. If this functionality is not allowed, or will not work (eg. if EWS is not published), then it can be disabled by changing this to False.

Saving information

AllowSaveCallLogs

AllowSaveIMHistory

These are set to True by default, and the client will keep around 100 entries of either. If the saving of this data is not allowed, set the values to False.

AllowSaveCredentials

This option is set to True by default, and like the “RequireWifi” settings, allows the user to choose. Even when the user signs out, the password field is pre-populated with their saved password. Setting to False means the option is not shown.

I have a separate post coming, detailing how authentication works in Lync 2013 mobile. Recent clients make use of client certificates to authenticate, making the saving of AD credentials redundant. In most environments, I would recommend setting this to False.

A quick Powershell tip – using Get-Random

The Get-Random cmdlet is worth knowing about – as well as getting you a random integer number (you can set a range), it can also randomly choose one of a number of objects.

How is this useful? Let’s say you’ve set up paired Lync Server 2013 pools and want to move a batch of users to them, keeping a fairly even split between the pools. There are plenty of ways to achieve this, but a really effective, simple way is to use Get-Random to pick a pool for you. It’s compact enough to use in one-liners as well as scripts.

We specify the options to pick from with the -InputObject parameter, and separate the options with commas.

For example, we’ll move the Lync users in the Accounting OU to our new paired pools:

Get-CsUser -OU "ou=Accounting,dc=contoso,dc=com" | Move-CsUser -Target (Get-Random -InputObject "ukpool1.contoso.com","ukpool2.contoso.com") -Confirm:$false

Lync 2013 – Windows Fabric installation failure code 1603

An installation issue I saw recently at a customer. Pre-requisites all went on fine, but when doing the Lync install, I hit an issue with Windows Fabric. I was installing at the command-line and saw:

Checking prerequisite WinFab…installing…
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  failure code 1603

winfab-error1

Running via the Deployment Wizard shows the following:

Checking prerequisite WinFab…installing…failure code 1603
Prerequisite installation failed: WinFab

A google search for those terms found this useful blog post but the suggestions didn’t work for me – the firewall service was stopped, but having it running didn’t help, and the system wasn’t set to Italian region (which is on the Lync known issues list), but even so any changes to time format settings didn’t help either.

The fix, as it turns out, was a simple one. The Performance Logs and Alerts service had been disabled in the customer’s standard Windows Server build. Setting this service to Manual or Automatic allowed Windows Fabric to install correctly and the Lync install to proceed.

I did hit a few issues with Windows Fabric after this – if you see anything like the below (event 50006 on LS AppDomain Host Process), uninstall Windows Fabric via the Control Panel > Programs and Features, then reinstall Windows Fabric via the msi.

winfab-error2

 

Lync 2013 client – recording not working

A quick and easy one, but not immediately obvious.

A customer was having problems with recording meetings using in the Lync 2013 client. Attempting to record or use the Recording Manager would result in an error about MFReadWrite.dll being missing, or a crash with “Faulting module name: MFReadWrite.dll” referenced.

We found various online references to Logitech software, or the Citrix Receiver causing the issue, none of which applied to us. We did eventually realise that the version of Windows deployed on the laptop was the “N” edition of Windows 8.1.

The “N” editions of Windows were created following the European Commission ruling in 2004. Microsoft were forced to create an alternative version of Windows for European customers without Windows Media Player included – which is what the “N” denotes. Not having WMP means some of the recording components that Lync needs are missing.

Fortunately, it’s an easy fix. KB2835517 offers the download of the “Media Feature Pack” for 8.1 which replaces these components, and recording worked correctly once installed.

Persistent Chat – Server could not process your request

A quick and simple one from this week’s deployment of Lync Server 2013.

We got Persistent Chat up and running, created a category, and gave our test user rights to create rooms. Signed in to the Lync client, we selected “Create a Chat Room…”.

pchat-create

This launches a browser to:

https://<pool-web-fqdn>/PersistentChat/RM?clientlang=en-US

..and we were hit with this error: Server could not process your request. Please try again later.

pchat-error

No errors in the Lync or Application event logs, and the only reference to the error I could find was this blog post at pro-lync.be. However, that problem relates to SBA-homed users, which definitely wasn’t the issue here.

The answer was in the IIS log for the Lync internal web site – by default, under C:\inetpub\Logs\W3SVC<siteID>\ (usually the lower siteID is the internal site). We saw the requests for /PersistentChat/RM?clientlang=en-US – but the username was that of the user who had logged in to Windows, not to Lync.

When we logged in to the PC as the test user, signed in to Lync and tried again, we got the chat room management page as expected and everything worked fine.

LS User Replicator Event 30011

Here’s a quick little fix for an issue seen at a customer.

They have an empty forest root domain, as this was once considered good practice for security reasons (to protect the schema and isolate highly privileged accounts/groups such as Enterprise Admins) and they have stuck with it since. Lync is deployed in the child domain, with no rights into the root.

They were seeing an error like the following the the event logs, every 20 minutes:

Log Name: Lync Server
Source: LS User Replicator
Date: 08/08/2013 14:18:56
Event ID: 30011
Task Category: (1009)
Level: Error
Keywords: Classic
User: N/A
Computer: LYNCSE01.childdom.customer.net

Description:
Encountered an unrecognized error while processing objects from a domain. This error caused User Replicator to abort synchronization of this domain. Synchronization will be retried for this domain. If this domain is not enabled for Lync Server, then this error can be ignored.

Domain: customer.net (DN: DC=customer,DC=net) Error: 50 (Insufficient Rights) ReplicationType:AddressBookReplication.
Cause: The cause for this error can vary. Please review the errors listed above.
Resolution: Contact support services if the error is not descriptive enough to remedy the problem.

The reason for the error is that by default, the User Replicator looks for all domains and tries to sync with them. User Replicator is the component that looks at Active Directory and pulls information into the Lync user database, ensuring any changes in AD (such as a user’s display name) are also reflected in Lync. With no rights in the root domain, it cannot read any information and errors.

Easily fixed however, via the Set-CSUserReplicatorConfiguration cmdlet:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add=”dc=childdom,dc=customer,dc=net”}

Change the last part to reflect the distinguishedName (DN) of your user domain(s). By default, the list of contexts is empty – setting one or more will tell the User Replicator to just look at those.

Fictitious telephone numbers

Most countries publish a telephone numbering plan, and this comes in very useful when setting up dial plans and normalization rules for Lync. It wasn’t until I was delving into the UK numbering plan that I found that large blocks of numbers in the UK are specifically reserved for “drama purposes” – in other words to use in films and TV shows. They are not allocated to anyone, and should not be allocated in the foreseeable future. This is much like the 555 convention used in the USA.

The full list is here – a total of 20,000 numbers to choose from! They include most major UK cities/areas, as well as mobile, freephone, premium rate and non-geographic.

What does this have to do with Lync? There are a few situations where they can be useful:

  • Customer documentation, especially example numbers or in generic templates.
  • Testing dial plans and PSTN usages, particularly for premium rate where you might not want to connect to a real one and pay over £1 a minute!
  • Validating that numbers across different area codes normalize correctly.

Australia has a similar scheme – the ACMA have a list of numbers for drama.

I’ve not come across any for other countries though – if you know of any, please get in touch!

Error when installing Lync Archive or Monitoring databases

I hit an odd problem at a customer last week when trying to install the Lync Server 2013 Archiving and Monitoring databases on their existing SQL server. They had (sensibly) set up separate drives for SQL data and logs and wanted the Lync databases put on the correct drives. They usually put them on the root of the drive, no base folder.

I defined the database in Topology Builder, Publish Topology and got the Create Databases dialog. I manually specified the file locations:

sqlissue1

Yet the process fails with the little red cross – so what’s going on?

sqlissue2 sqlissue3

InstallDatabaseInternalFailure: An internal error has occurred while trying to create or update the database.

Error: Default path ‘H:’ obtained from Sql Server does not have a drive letter. Please check your SQL Server installations and try again.

The SQL Server event viewer shows 18456 events, saying that login failed – “Token-based server access validation failed with an infrastucture error”.

sqlissue4

So what is going on here? Some things I tried or verified:

  • Account permissions (sysadmin on instance, domain admin)
  • UAC disabled
  • Firewall disabled
  • Plenty of free space on the drives
  • Creating a database manually from the SQL server
  • Lync server could get to the instance OK via Management Studio and create a database
  • Tried creating folders on the SQL server drives and installing DBs to there
  • Using Install-CSDatabase cmdlet via the shell instead of Topology Builder

The culprit: the default paths for the instance were set to the root of the volume. In this state, it doesn’t matter what path you specify to install the databases to, it will always fail.

Workaround: change the default paths for the instance (even if only temporarily).

In SQL Server Management Studio, right-click on the instance, and select Properties.

sqlissue7

Under Database Settings, Default Database Location, change both paths to something else (it has to be valid, but can be anything as long as it’s not at the root of the volume). Click OK to save changes.

sqlissue6

The problem seems to be that when you specify the root of a volume, SQL Server does not keep the trailing backslash (eg. H:\ is stored as H:). The Install-CSDatabase cmdlet appears to retrieve the default path for the instance and SQL considers it invalid, even if you’ve told it to install to a different path.

Trying it now and it works fine, even with the same settings as before (installing to the root of the drives):

sqlissue8

Probably not a common issue but one to consider if you have problems installing the Monitoring or Archiving databases for Lync Server.

The customer (and my lab for screenshots) are on SQL Server 2008 R2 RTM. I have also tested with SP2 and the issue is the same. I’ll try out on SQL Server 2012 at some point to see if that does the same.