Quantcast
Channel: UC Geek - Lync and Skype for Business Specialist
Viewing all 116 articles
Browse latest View live

Lync call accounting for user or departmental billing

$
0
0
Wondering if there is a great demand out there for free solution to Lync call accounting? I have been playing around with SQL queries to see what I can do, and if there is a demand will spend some more time putting together something to share with the Lync community.

One of the difficulties in accounting for Lync calls is when a call is forwarded. Lync passes the A-Party caller ID through to the C-Party, and lists the B-Party who forwarded the call as the "referrer". This is included in the SIP header as Referred-By, and also included in the Lync monitoring server reports.

All the SIP providers I have dealt with here in New Zealand don't seem to cater for this situation. Instead I get call records that show A-Party called C-Party, with no indication of who actually initiated the call to the C-Party, and therefore should be charged to that leg of the call.

Its pretty crude, but here's what I am getting straight out of SQL so far:



Leave a comment and let me know what you think.



Understanding how Lync establishes audio/video paths using ICE

$
0
0
The real time aspects of Lync require a different approach to SIP signally to ensure a quality of service. SIP signalling can be delayed without causing too many issues, however audio/video this is much more important, and to do this Lync uses Interactive Connectivity Establishment (ICE). ICE is the overall process that helps discover and exchange candidates to finds most optimal media path.

Definitions

  • SIP signalling - allows clients to send invites to other parties.
  • Interactive Connectivity Establishment (ICE) - Process used to discover and exchange candidates in order to find the most optimal media path.
  • Candidates– A list of possible IP addresses that could be used to establish a media path.
  • Reflective/Session Traversal Utilities for NAT (STUN) - STUN reflects or returns the public NAT address to the Lync client e.g. a home based user sends a packet to edge server, which discovers the public IP address (a candidate) , and returns it to the client.
  • Relay/Traversal Using Relays around NAT (TURN) - TURN allows the media traffic to be relayed/proxied by the Edge server to the client by providing the client a relay addresses to send media.
  • ICE endpoints– An ICE endpoint is anything that is involved in media e.g. Lync Clients, Lync Web App, Lync Phone, FE Server (App Sharing MCU, RGS, Call Park A/V Conf etc), Mediation Server, SBA, Exch UM. Session Border controllers and the director role would not be considered as ICE endpoints. Edge server is doing STUN and TURN but not an ICE endpoint, more and ICE server.

The 5 Phases of Media Path Establishment

1. TURN provisioning and credentials (MRAS)
The Lync client does an SRV lookup to find an Edge server to register against and then performs a SIP register. The server provides a 200 OK which includes in band provisioning details, including MRAS (media relay authentication services) which tells the client there is an Edge server service deployed. With this the client sends SIP service request to Front End which includes the client’s location (internal or external). Because the Edge is not on the domain it can’t authenticate client directly, so the Front End server requests the credentials on behalf of the client. The AV Edge service creates credentials using AV Edge certificate for the Front End which sends a 200 OK back to client with the Edge server it should connect to, ports and username and password. Credentials are valid for 8 hours and for this period the client can now go straight to Edge server. In conferencing scenario the same thing happens, however because can join anonymously the Front End checks to see if a meeting exists, and then gets and passes the credentials to meeting participant.



Tip - Always make sure you use the same external certificate for all Edge servers. The certificate is used to create credentials for the client to connect. If an Edge server goes down, and the client try’s to connect to another Edge server using a different certificate, it will not be able to validate the credentials and authentication will fail.

Search for “MRAS” in Snooper to find authentication messages. There should be 3 messages per request. Port 5062 for MRAS.

2. Address Discovery (Allocation)
Address discovery is the process the client goes through to determine what IP addresses it might be reached on. These IP addresses are the client’s candidates.

Audio/Video
  • Discover local UDP candidate for every network card (peer to peer so UDP is best)
  • Connect to media relay (Edge server) to discover reflexive address (the address the Edge server sees the client connect from) and allocate a candidate on the media relay for UDP then TCP
File Transfer and Desktop Sharing (RDP over RTP) - Both require TCP
  • Discovers local TCP candidate
  • Media Relay TCP only

3. Address Exchange (SIP Invite/200OK)
Address exchange is the process of sharing candidates with other endpoints that will be part of the call (peers). This is achieved by sending a SIP invite to the peer, who in turn will discover their own candidates, and send them back as part of a SIP 183 Session Progress.

4. Connectivity Checks
This is the process of taking the provided candidates and determining a possible media path. The Lync client validates the list of candidates by opening connections to all entries in the list simultaneously. The first to respond is used to establish the “Early Media” connection, however the media path may change during the call using a process called candidate promotion. When the called party picks up it will again send its candidates to the caller, but this time part of a 200OK.

  • Connect directly (peer to peer)
  • Connect to reflective address
  • Connect via media relay by connecting to the Edge and asking it to contact a candidate and establish a connection on its behalf.
**If there is no Edge server it only does local candidates.

5. Candidate Promotion
This is the process of determining the best possible candidate for the session. If a better path is found the then media path can change during the call.
  • Host/Local Candidate (UDP) – The most preferred candidate is always a local candidate and is the reason that peer media sessions between clients on the same network will never use the Edge server.
  • Reflexive/STUN Candidate (UDP) – The next preferred option is to use the server reflexive candidate which is provided by the Edge Server using STUN. This scenario involves attempting to connect to the reflexive IP addresses for each externally connected user. The reflexive IP address is the public IP address of the external user e.g. a home router.
  • Relay/TURN Candidate (UDP) – In the event that STUN fails then the final option is to utilise the Edge Server as a media relay. The calling client will establish a media session directly with the A/V Edge Server as will the receiving client. This connectivity is relayed through the public IP address of the Audio/Video Edge service.
  • Relay/TURN Candidate (TCP) – when connectivity is not available on UDP. TCP Relay is a last resort.


SIP Messages in Media Path Establishment


  • Out INVITE (SDP session description protocol – tells other party what I can do e.g. codecs). First set of candidates is ICE v6 (ms-proxy-2007fallback) second set is ICE V19. OCS r2 + uses V19 includes both for back compact. Candidates come in peers - one for RTC and one for RTCP.

    A=candidate 1 1 Protocol(UDP/TCP Passive – candidate they I expect to send traffic to /TCP Active – candidate that sends me traffic) priority (high best) IPAddress Port Typ(host/relay/server reflective)

    A=candidate 1 2 UDP priority(high best) IPAddress Port Typ(host/relay/server reflective).

  • In SIP 183 Peer sends its candidates. You may see multiple – one for each end point.
  • In SIP 200 OK Peer picks up the call. This still includes a full candidate set as the best have not been negotiated yet.
  • Out INVITE Re-invite which will include the 1 chosen candidate peer as decided in the earlier process.
  • In SIP 200 OK Includesother party’s final candidates.
NOTE: The Edge server is used in discovery process, but not necessarily once media path has established. This is why it can be important for internal clients to be able to access the internal NIC for edge. If the candidate list doesn’t include UDP and TCP reflective then it probably can’t talk to Edge server. If you see only UDP or only TCP then firewall might be blocking ports.

Call Scenarios and Connections Options

Inside <-> Inside
  • Peer to Peer
Inside <-> Outside
  • Peer to peer will not work
  • Outside connects to reflective candidate UDP or TCP
  • Outside connects to own edge server (relay) which hairpins traffic to internal user


Outside <-> Outside
  • Peer to peer might work if clients are on the same network
  • Reflective candidate UDP or TCP
  • Relay via Edge server


Federation OCS 2007
  • Edge servers connect to each other on the 50k port range directly and relay the call. Ports need to be open in both directions.
Federation 2007 R2 (tunnel mode introduced)
  • The Edge server sends a special packet to UDP port 3478 on the other Edge to find out if it is OCS 2007 R2 or above. If it is then tunnel mode can be used, and all UDP traffic can be sent on these ports. Candidate data still includes the 50k ports, but the Edge server just contacts the other Edge server to share this information and connect.
  •  TCP is very similar, but because a connection to a source IP/port and destination IP/port can only be in use at one time, the Edge server allocates a port in 50k range as a source port, and then opens a connection to the other Edge server on port 443. This gets around having to have 50k ports open which is required for OCS 2007.

While the 50k port range is not required for OCS 2007 R2 and above, there are still benefits to opening it. In a situation where 2 Edge servers would normally be involved in relaying media, this situation allows both clients to connect to the same Edge server. The initiating client connects to its home Edge server, gets candidates and passes those to the other party. The other party then attempts to connect to the 50k range directly on the initiators home Edge server. Without these ports open this would not work, and the client would need to involve its own Edge server and ask that it connects to the initiating Edge to relay on its behalf. This introduces a longer media path.

Troubleshooting Media Connectivity

  • Get client login from fresh sign in – is there MRAS? If no it can’t talk to edge.
  • Check if FE can telnet to FQDN on internal edge
  • Check logs for STUN and TURN candidates. If none then there is an issue between client and edge
  • User port query to test UDP
  • When edge sends candidates in NAT situation, edge uses external IP configured in topology and sends this to client – make sure it’s correct.
  • Search Snooper logs for MRAS for authentication
  • Search a=candidate to see candidate
  • Search a=remote-candidate to find final candidates that are chosen
  • After call pickup it can take several seconds before final candidates are chosen, and media path might change. Final re-invite will include this but the result may not be in logs for a few seconds after connection.

Thanks to Thomas Binder for thisexcellent deep dive as well as Jeff Schertzfor his summary.


Lync 2013 Client Installation and Activation

$
0
0
Lync 2013 now comes as part of Office 2013 ProPlus, or can be downloaded separately as a 700MB iso image. Both versions now require a valid licence key to activate, however there is also a free “Basic” client which doesn’t support Enterprise Voice features such as forwarding. The Lync 2013 basic client can be downloaded here – x32x64.

When installing Office 2013 ProPlus a licence key can be can be entered during setup, however in my experience the standalone Lync 2013 installer just activates a 60 day trial. I know this because after 60 days users started complaining they were getting prompted to activate the software! This was the first time I learnt about the requirement for a licence key in Lync 2013. The Lync 2010 clients didn't not have this requirement, and were only a 60MB download – not sure what happen there Microsoft!

As Office does, the standalone Lync installer also supports the Microsoft Office Customization Tool. We can use this tool to specify the product key to be entered during installation.

Open a command prompt window. To do this search “CMD” from the start menu and right click to “Run as administrator”, select “Yes” to run if prompted:




Type cd “<path to installer>” e.g. cd "C:\installs" (make sure you include brackets if you have spaces), hit enter then type “setup.exe /admin” to start the customisation tool:











Select the product and click “OK”:







Under “Licencing and user interface" select “Enter another product key” and enter your key. You can also accept licence terms on behalf of the user, and specify the installation display level:




Once you are completed with configuration select “File” – “Save As” and save to your installation directory:




Now go back to the command prompt window and run setup.exe /adminfile “<path to file you just created>” e.g. setup.exe /adminfile "C:\installs\LyncSetupFile.MSP":



Setup should now start and begin installation:






Lync call accounting for user or departmental billing - beta v0.2

$
0
0
Following up on my previous post questioning the need for a free Lync call accounting solution, I would like to thank those who have provided feedback, and the motivation for me to get the first beta release ready for the Lync community.

This is very much a beta so please use with caution. Depending on the size of your AD environment and call volumes, the script can take quite some time to complete. In my demo environment I am processing about 15 call records per second, so a date range that involves 15,000 call records will take about 15 minutes to complete. I will look at ways to make it more efficient in future releases, but suggest for now you keep the date query range to within a month and process overnight. You could also modify the script to process daily and append to a CSV file.

At this stage I don't have a detailed guide on how to use the PowerShell script, however hopefully the comments in the code will be enough for now. Please feel free to get in touch if you need any assistance or have any ideas to improve the script.

How it work's

Firstly the script query's SQL for call records within the specified date range. It then queries active directory for the users sip address that is identified as the party to be charged, and if a match is found includes this in the report. The matched users company and department details will also be included so that charged calls can be identified per department.

Some of you may notice that the tariff and rate information shown in the example output has been removed from this release. This is because the calculations are fairly complicated and need more testing to be reliable.

Instructions

1. Download the script from here
2. Unzip the file and extract to the location of your choice
3. Open the LyncCallAccounting_beta_v0.2.ps1 file and update the settings to match your environment
4. Run the script as admin

Notes

1. The credentials used to run the script will be passed to SQL for authentiacation. Make sure that you account has the required permissions.

I encourage your feedback to help grow this script in to something more mature. 

Minimum Update Level for Lync 2010 to 2013 Migration

$
0
0
Microsoft's guidance when migrating Lync 2010 to Lync 2013 is to install the latest cumulative update for Lync 2010. This would also be my recommendation, however if you are wanting to know if you current Lync 2010 infrastructure can support a migration to Lync 2013, the minimum requirement is Lync 2010 CU6 (June 2012). This was the latest update at the time Lync 2013 Preview was released.


Install or Update Lync Server System - What does it do?

$
0
0
What does the "Install or Update Lync Server System" step in the deployment process actually do?

This step is essentially like running a setup installer that adds or removes components, and updates configuration. Rather than collecting the setup information from the user who runs it, instead it connects to the Central Management Store (CMS) to determine the servers role, and therefore the components that need to be added, removed or updated.

Unlike most setup installers that are run once, Install or Update Lync Server System is commonly run after changes are made to the topology. I haven't come across a list of topology changes that require it to be run, but here are a few situations I know about:

  • If you have added or removed a role from a Lync server you should run on the effected server
  • Additional or removal of a SIP domain
  • Change to meeting, dialin or admin URL's
  • Any other change that may effect Lync web services

If you have anything to add or I have got anything wrong please let me know.




Lync 2013 migration - Cannot sign-in when IPv6 enabled

$
0
0
After nearly a day trying to figure out why a newly deployed Lync 2013 pool would not allow users to sign in, and just before I was about to pull my hair out, I found IPv6 was to blame. Normally I would always disable IPv6 during server preparation, however in this case the job was already done for me and I didn't check. Now the weird thing here, is that Lync 2013 supports IPv6!

Here is the original description of the problem I posted on TechNet:
"I have 3 domains in 3 country's. US and Australia has a working Lync 2010 deployment, and we have just added a new site in the New Zealand domain with Lync 2013 (eventually the other sites will be migrated to Lync 2013). The Lync 2013 Front End has been installed and all services are running. I have enabled the first test user in the Lync Control Panel successfully . When I go to sign-in I get an error along the lines of "try again or check with your administrator". On inspection of the client logs I can see that client sends a SIP register, the server responds with the available authentication methods, the client then trys again with using Kerboros and the server responds with SIP/2.0 404 Not Found - ms-diagnostics: 4005;reason="Destination URI either not enabled for SIP or does not exist". The use account is valid and I can log on to a workstation successfully with the same account.
We have not yet run enable-cstopology on the Lync 2010 FE's as this is not normally required. However to be safe this is currently going through change control. Something that isnt common in a migration is adding a new SIP domain (for New Zealand) and new meet and dialin URL's. This makes me think that running enable-cstopology on the Lync 2010 FE's will fix it.
The other thing that springs to mind is domain secuity on containers and OU's etc"

Just in case IPv6 was a red hearing I better let you know that about an hour before I changed the user replication cofiguration. Get-CSUserReplicatorConfiguration identified that only the domains where Lync 2010 existed where part of the user replication cycle. To fix this issue I added the domain, ran a sync and rebooted for good measure.

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add=”DC=Lync2013,DC=Domain,DC=com”}

Update-CSUserDatabase

This did not produce any immediate results, however you never know, time can be a healer.




Using Lync in a Remote Desktop Environment

$
0
0
When moving to Lync one of the major hurdles for a business is what to do with remote desktop users. Because all the processing is server side, the real-time features of Lync are a little trickier to deliver to the thin client or remote PC. This article is an effort to help explain the different scenarios and how best to deal with them.
This article directly refers to Microsoft technologies, but similar options are available with other vendors e.g. VMware Horizon, Citrix XenApp and XenDesktop

Remote Desktop Session Host (RDSH)
The most common remote desktop delivery method is via a session host server, or more commonly known as a terminal server. Windows Server 2008 SP1 introduced RemoteFX, bringing with it a more advanced version of the RDP compression scheme, that allows for more efficient streaming of both video and audio. This provides a better experience compared to RDSH without RemoteFX enabled, but has fewer capabilities compared to RemoteFX with Remote Desktop Virtualization Host (RDVH/VDI) which is talked about further later in this article.

Audio
Out of the box most current versions of RDP will support remote audio regardless of whether RemoteFX is used or not. This is very basic and delivers the audio stream over the RDP protocol.

In the Remote Desktop client find “Remote audio” – “Settings…”:



Make sure that “Remote audio playback” is set to “Play on this computer” and “Remote audio recording” is set to “Record from this computer”:



Once you have made the changes log back in check the “Audio Device Settings” in the Lync client, making sure that your speaker and microphone are using “Remote Audio”. If you don’t see the remote device try restarting the Lync client or logging out and back in again:




While this method works, it is not likely to be as good as a directly connected Lync Client.

Video/Media
Video and rapidly changing media is likely to struggle when delivered via session host, and thus is not recommended. As described above, RemoteFx will provide improvements, but is still not perfect.

USB Redirection
With RemoteFX USB redirection is not possible for direct RDSH connections to Windows 2008 R2 SP1 by itself, with or without GPU. But you can use certain USB devices via other mechanisms (e.g. a USB flash drive may be accessed via Drive Redirection). RemoteFX USB redirection is available for direct RDSH connections to Windows Server 2012.

Remote Desktop Virtualization Host (RDVH/VDI)
VDI is an emerging technology thatuses virtualisation to compartmentalise user desktops using a “Golden Image” with differencing technology to save individual user changes. In conjunction with RemoteFX, VDI provides vast improvements for real time services as well as USB redirection.

Audio/Video/Media
Lync 2013 fully supports VDI by taking advantage of the new Media Redirection architecture introduced in Server 2012, which allows Voice over IP (VoIP) applications to natively integrate with RemoteFX, and enables transmission and rendering of audio and video content directly on the client side. The Lync VDI Plug-in is a stand-alone application that installs on the local computer, and allows the use of local audio and video devices with the Lync 2013 client running on the virtual machine. The plug-in does not require Lync to be installed on the local computer. After the user signs in to the Lync 2013 client that is running on the virtual machine, Lync prompts the user to re-enter his or her credentials, in order to establish a connection with the Lync VDI Plug-in that is running on the local computer. After this connection is established, the user is ready to make and receive audio and video calls. This approach means that audio and video originates and terminates at the client rather than the server.

Advantages with VDI:
  • Audio and video performance similar to that of running Lync locally. Since a double hop of media content is avoided, even WAN users can have a great Lync audio/video experience.
  • Reduced bandwidth usage between the client and the data centre because Lync media content is not sent from the server-based desktop anymore.
  • Improved server scalability because CPU intensive media processing happens on the client side.


VDI Feature Limitations
  • There is limited support for Call Delegation and Response Group Agent Anonymisation features.
  • There is no support for the following features:
    • Integrated Audio Device and Video Device tuning pages
    • Multiple-view video
    • Recording of conversations
    • Joining meetings anonymously (that is, joining Lync meetings hosted by an organization that does not federate with your organization)
    • Using the Lync VDI plug-in along with a Lync Phone Edition device
    • Call continuity in case of a network outage
    • Customized ringtones and music-on-hold features
    • The Lync VDI plug-in is not supported in an Office 365 environment.

USB Redirection
RemoteFX USB Redirection for Remote Desktop Virtualization Host (RDVH) in Windows 7 Service Pack 1 was available only to those deployments that enabled the RemoteFX vGPU. With Windows Server 2012, USB Redirection is now available to any RDVH deployments, with or without the RemoteFX vGPU.
USB devices can now be selected for redirection even in the middle of a remote session, and can be swapped between remote sessions or to the local PC. When RemoteFX USB Redirection is enabled, simply tap the new Devices icon on the Connection Bar to choose which devices are redirected.



The Remote Desktop Connection dialog box allows you to choose USB devices that you want to use in your remote desktop session.


RemoteFX for RD Virtualization Host server hardware requirements
For Windows 7 SP1 VMs, RemoteFX USB redirection requires that the vGPU be installed in the VM (and thus the 2008 R2 SP1 host must have the required GPU and SLAT). But for Windows 8 VMs, the vGPU is no longer required – you simply need to have the Enterprise SKU of Win8 in the VM
The GPU is no longer necessary to achieve USB redirection on connections to Windows 8 physical desktops or Windows 8 VMs running on Windows Server 2012, or Windows Server 2012 RDSH. All other scenarios will still require the vGPU.

Comparing Remote Desktop Virtualization Host (RDVH/VDI) & Remote Desktop Session Host (RDSH) (Based on Server 2008 R2)
RemoteFX w/ Remote Desktop Virtualization Host (RDVH/VDI)
  • Rich user experience for Virtual Desktop Infrastructure (VDI) via
    • 3D virtual adapter
    • intelligent codecs
    • ability to redirect USB devices in virtual machines 
  •  Requirements
    • RemoteFX enabled on a Remote Desktop Virtualization Host server
    • Windows 7 Enterprise/Ultimate running in a VM on the RemoteFX server
    • RemoteFX compatible client
    • Server-based GPU and other HW requirements as defined in this article
    • Remote Desktop Connection performance set to LAN (10 Mbps or higher)
  • Result
    • Full fidelity experience (e.g., 3D applications built on DirectX, Silverlight and Flash applications, etc.)
RemoteFX w/ Remote Desktop Session Host (RDSH/Terminal Server)
  • Rich user experience defined as:
    •  lower bandwidth usage as compared to Windows Server 2008 R2 when transferring rich graphics applications (i.e., intelligent codecs provide a better experience)
    • Does not provide the same experience as RemoteFX w/ Remote Desktop Virtualization Host (RDVH/VDI)
  •  Does not provide:
    • 3D virtual adapter
    • ability to redirect USB devices in virtual machines
  •  Requirements
    • RemoteFX enabled on a Remote Desktop Session Host server
    • RemoteFX compatible client
    • Remote Desktop Connection performance set to LAN (10 Mbps or higher
    • No server-based GPU is required
  • Result
    • Provides a better experience compared to Windows Server 2008 R2 without RemoteFX enabled but has fewer capabilites compared to RemoteFX w/ Remote Desktop Virtualization Host (RDVH/VDI).




SIP Address Doesn't Match Email Address

$
0
0
By default if your Lync SIP address doesn't match your primary SMTP email address, then Outlook integration will not work. You can resolve this by disabling the client policy DisableEmailComparisonCheck using the following PowerShell command.

Set-CsClientPolicy -DisableEmailComparisonCheck $true


Lync 2013 Exchange Integration

$
0
0
Lync and Exchange/Outlook integration can cause a fair bit of frustration, in particular when the Lync and Exchange servers are in different AD forests. For example one company might leverage another companies Lync infrastructure, while maintaining there own Exchange infrastructure.  This article details my experiences, and is by no means definitive, or even true for all circumstances. I welcome your feedback and own experiences.

There are 3 options available to Lync to provide Exchange/Outlook integration - Exchange Web Services (EWS), MAPI or a combination of both. If EWS can be resolved the Lync client will attempt to authenticate using the same credentials it has stored for the Lync client logon, or NTLM authentication for the logged on user. If it fails it will not give you the chance to enter different credentials, and as a result EWS authentication will fail. If EWS cannot be resolved or authentication fails, Lync will still attempt to connect to Outlook using MAPI. You may be prompted for credentials, however generally if Outlook is already open, then MAPI authentication has already occurred.

This behavior creates 3 scenarios:
1. If EWS is resolved to the Exchange infrastructure where Lync also resides, then the Lync client will authenticate to EWS using the saved Lync credentials successfully, and will also connect to the MAPI account locally.
2. If EWS is resolved to an Exchange infrastructure outside where Lync resides, then the Lync client will fail to authenticate using the Lync logon credentials, however should succeed if it is able to pass though the NTLM credentials of the logged on user. As above MAPI should also succeed.
3. If EWS is not resolved, then the Lync client will only use MAPI integration.

Enabling the scenarios and their pro's and con's

1. Use EWS provided by the Exchange infrastructure where Lync also resides

In this case we populate the Lync users AD "Email" address field with an email address which has a domain name matching that of the Exchange autodiscover service in the Lync environment. The email address doesn't necessarily need to be valid.

**When you enable the Lync user account for Exchange and Unified Messaging, this step is not required since the "Email" field will automatically be populated with the default SMTP address.

Advantages

  • Provides a mixture of EWS and MAPI from both Exchange environments
  • Lync client visual voicemail will work
  • Lync client conversation history will work

Disadvantages

  • New Lync Meeting creation from Outlook will not work, and you will receive the following error message "You cannot schedule the Lync Meeting because you are not UC enabled or there may be issues with your Communications Server account. Make sure you are signed in to the same account you use for Microsoft Outlook. If the problem continues, please contact your support team"

    **If you temporarily apply option 2 below, create an Outlook Lync Online Meeting then revert back to option 1, it appears this will keep working. There is also a registry key that could be created manually, but I have not tested this (HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\ConfAddin).
  • Occasionally Exchange integration is slow to establish, or will not establish at all. This situation can normally be resolved be signing out and back in again.
  • MAPI relies on Outlook being installed and setup with the account you want to integrate with on the computer where you are running Lync. 


2. Use EWS provided by an Exchange infrastructure outside where Lync resides

In this case we populate the Lync users AD "Email" address field with an email address which has a domain name matching that of the Exchange autodiscover service in your local Exchange environment. This would normally be the users actual primary SMTP address.

Advantages

  • New Lync Meeting creation from Outlook will work
Disadvantages

  • Lync visual voicemail will not work. This does not stop voicemail working, and voicemail messages can still be delivered to your inbox (by way of forward), however to configure voicemail options requires login via OWA.
  • Lync client conversation history will not work, however it will still be stored in Outlook "conversation History" folder.
  • Users may be prompted to verify the certificate used by the autodiscover service
  • The "Email" address field is displayed on the Lync contact card (see workaround here)

3. Don't use EWS

In this case we populate the Lync users Active Directory "Email" address field with an email address which has a domain name not associated to an Exchange autodiscover service. This ensures that EWS is not resolved and only MAPI will be used.

Advantages

  • None
Disadvantages

  • Not all features are available over MAPI

Clearly option 1 is the best bet in terms of functionality. It has certainly worked for me in the past, but I am sure there will be cases where it just wont work.


Disable Email Comparison Check

Regardless of which option you select you will need to change the Lync client policy to allow the users SMTP address to be different to their SIP address. This can be done with the following command:

Set-CsClientPolicy -DisableEmailComparisonCheck $true


More Information

More information on Lync and Exchange/Outlook integration see the following TechNet articles:
Lync 2013 Compatibility - http://technet.microsoft.com/en-us/library/gg412817.aspx
Lync 2010 Integration (no comparable article for 2013) - http://technet.microsoft.com/en-us/library/gg398806.aspx



Lync MVP

$
0
0
Excited to learn this morning that I have been become a Lync MVP! Well at least I hope I'm a Lync MVP, I'm listed for CRM but hope to get that sorted after I talk to Microsoft....



.

Troubleshooting Lync Address Book Issues

$
0
0
Client Cache
The Lync client periodically downloads the address book via the internal or external web services. Trydeleting the client cache.

Try deleting .lsabs, .dabs, GalContacs.db and GalContacts.db.idx cache files from %userprofile%\AppData\Local\Microsoft\Communicator\sip_<username@domain>\ (exit Lync first).

Server Cache

  1. Delete the address book files from the server located here - \\LyncShare\1-WebServices-1\ABFiles\ 
  2. Once deleted run Update-CsUserDatabase from Lync Management Shell (Synchronizes data between AD and Lync backend DB)
  3. Wait at least 15 minutes
  4. Run Update-CsAddressBook  from Lync Management Shell  (Writes changes in backend DB to the address book files)
This will regenerate all you address book files.

Active Directory Sync Normalisation
If numbers are already in E164 format then normalisation rules should not come in to play. If normalisation is coming in to play it is done with Company_Phone_Number_Normalization_Rules.txt. Rules in this file will allow AD numbers to be normailised when added to the Lync address book. Check for any normalisation errors in the Invalid_AD_Phone_Numbers.txt text file - \\LyncShare\1-WebServices-1\ABFiles\00000000-0000-0000-0000-000000000000\00000000-0000-0000-0000-000000000000\Invalid_AD_Phone_Numbers.txt

Useful Articles:
http://y0av.wordpress.com/2012/02/23/normalize_ad_numbers/
http://blog.schertz.name/2010/09/updating-the-lync-2010-address-book/

Understanding Exchange UM Name Lookups

$
0
0
Unified Messaging uses two data sources to receive information about the calling party and to map it to the name of the caller: Active Directory and personal Contacts. When the name lookup process is successful, the name of the calling party will be inserted into voice mail messages and missed call notifications if they've been enabled for the called party. When an incoming call is received, the calling party information is passed to a Unified Messaging server.

In Exchange 2007, name lookups for voice mail messages are done by using information about a caller who's in the same dial plan as the user being called in one of the following ways:
  1. Using an EUM proxy address.
  2. From the personal Contacts of the user receiving the call.
  3. Using the msRTCSIP-Line attribute in Active Directory if Service Pack 1 (SP1) for Exchange 2007 was installed and Exchange 2007 was integrated with Microsoft Office Communications Server 2007 or Office Communications Server 2007 R2.
In Microsoft Exchange Server 2010, the name lookup methods differ from those used in Exchange 2007. The following steps are used in Exchange 2010 to look up a name from the calling party's information:
  1. The caller's name is used if the caller signed in to their mailbox from Outlook Voice Access or if they use a Microsoft Unified Communications client such as Microsoft Office Communicator 2007 or Communicator Phone Edition to place the call. The caller's identity is known because they've been authenticated when they use Outlook Voice Access, Office Communicator 2007, or Communicator Phone Edition.
  2. The EUM proxy address or addresses in Active Directory are used. If the proxy address contains an '@' sign, it's considered a SIP URI. If the proxy address begins with a '+' character, it's considered to be an E.164 number. If neither of these characters is present, the proxy address is considered an extension within the same dial plan as the called party or an equivalent dial plan. 
  3. If the caller ID is a valid SIP URI, Active Directory is used to resolve the SIP URI using the EUM proxy address or addresses. 
  4. If the caller ID is a valid E.164 number, Active Directory is used to resolve the number to the calling party's name. For this to work correctly, you must have manually configured the UMCallingLineIds parameter on the UM-enabled mailbox for the called party. This configuration is useful when you don't want to publish a telephone number, such as a personal mobile phone number, in Active Directory, but still want to resolve the calling party's name by using this phone number.
  5. Active Directory heuristic matching is used, if it's enabled, to resolve the number to the calling party's name. Active Directory heuristic matching must be enabled on the dial plan, and the user's account in Active Directory must be populated with one or more of the fields, such as telephone number, home, or mobile, for this to work correctly.
  6. The personal Contacts of the called party are used to resolve the number to the calling party's name.


Improved E.164 Number Resolution
In Exchange 2010 Unified Messaging, four new methods are used to improve resolution of the caller ID to the calling party's name.
  1. Calling Line ID's

    In Exchange 2010, a multivalued attribute named msExchUMCallingLineIDs was added to the Active Directory schema. This attribute enables a UM server to take an E.164 number or set of numbers, convert the number or numbers, and then perform a name lookup. This attribute can contain a list of numbers that are mapped to a specific user and can be configured on the user's Active Directory object. For example, you could add the numbers, 4255551010, 14255551010, and +14255551010 to the msExchUMCallingLineIDs attribute for a specific user. Although the last number in this list is an E.164 number, a correctly formatted E.164 number isn't required. You can add any phone number that looks like a valid phone number that contains digits, and those digits can, optionally, begin with a plus (+) sign.

  2. Number Plan Formats for Dial Plans

    This is a form of number normalisation so the Exchange can correctly match a caller ID to an AD user. When a UM server answers an incoming call, it reads the caller ID. The UM server will parse the list of configured number plan formats from the top down until a match is not found or there's a conflict in the digits where x in the number mask is treated as a wild-card. When this happens, the UM server will try to back fill the caller ID for the incoming call into each number mask.

    For each UM dial plan, there's an msExchangeUMCallingLineIDFormats attribute that can be configured using the NumberPlanFormats parameter to specify one or more phone number masks that can resolve caller IDs to names in Active Directory. The following figure shows this attribute and the numbering plan formats.

  3. Active Directory Heuristics

    Exchange UM can use the phone number fields, such as telephone number, home, or mobile, that are configured for a user who's in Active Directory. However, there’s no way to select which of the phone fields to include. The following telephone attributes for a user in Active Directory will be used to resolve a caller ID to a name:

    • telephoneNumber
    • homePhone 
    • mobile
    • facsimileTelephoneNumber 
    • otherTelephone 
    • otherHomePhone 
    • otherMobile
    • otherFacsimileTelephoneNumber















    This is controled by the msExchAllowHeuristicADCallingLineIDResolution attribute on each dial plan, and is set to true by default.

    Potential issues that prevent resolution of a caller ID to a name:
    • The administrator didn't enter a number in the Telephone number field.
    • The administrator doesn't use the Telephones tab at all for phone numbers.
    • E.164 numbers are entered without any parentheses, hyphens, or the correct spaces.
    • The numbers aren't in the correct E.164 format. Examples of the correct format include the following:
      • (425) 555-1010
      • (425) 555-1234 x51010
      • (425) 555-1234 ext. 51010
      • 425-555-1010
      • 425.555.1010
      • 425/555-1010
      • 1425-555-1010
    • Both extensions and international numbers are used. Examples that show both extensions and international numbers used together include the following: 
      • +7890
      • +441234567890
      • +44(1)234567890
      • +44 (0)1 2345 6789
  4. Equivalent Dial Plan Groups

    The concept of an equivalent dial plan has been added in Exchange 2010 Unified Messaging to allow UM administrators to connect two dial plans that are in the same PBX numbering plan but are broken into two dial plans. Two dial plans might be contained in a single PBX numbering plan, for example, when users in the two separate dial plans sit next to each other and can dial each other using an extension number but exist in different dial plans for reasons unrelated to the telephony infrastructure.

    For every dial plan, there can be an equivalent dial plan phone context for two or more dial plans that should be one dial plan but have been separate. You can add names for other dial plans and link to other dial plans. The dial plans you enter names for or link to can be in the same Active Directory forest or in different forests. When you add an equivalent dial plan, the dial plan’s phone context will be automatically added to the equivalent dial plan group.

Voicemail and Missed Call Notifications

When Exchange UM processes a missed call or voice mail, it saves the metadata to a text file on the local disk prior to sending an email to the hub transport. If the hub transport is not available, the files remain on the local disk. By default, the files are stored in the %ProgramFiles%\Microsoft\Exchange Server\v14\UnifiedMessaging\voicemail folder.



Missed Call Metadata

Voicemail Metadata














More Information

Lync Users Can Login After Domain Account Is Disabled

$
0
0
A few months ago it was brought to our attention that disabled users were still able to sign-in to Lync. Thinking this was crazy talk I set out to figure out how this was possible, and stumbled across Jeff Guillet's article Disabling a User in AD Does Not Disable the User In Lync. Wanting to understand the process better I tested Jeff's findings on Lync Server 2013.

Lync Server has 3 options when it comes to authentication - Kerberos, NTLM, and certificate based. Kerberos is the default authentication method for authenticating clients on the domain, while NTLM is used when authenticating externally via the Lync Edge servers. If the user selects "Save my password" during sign-in, Lync server will generate a X.509 certificate and publish it to the RTC database, as well as the current users local certificate store on their PC. The certificate is valid for 180 days and will be used for authentication from then on, and as a result the users AD account will not be checked during sign-in. The certificate can be revoked or deleted from the client to enforce re-authentication using domain credentials, however this will not affect signed in users immediately, and its interesting to note that if the domain credentials are still valid, they will still sign automatically downloading a new certificate in the process. For near immediate results you should use the Lync Server Control Panel to "Temporarily disable for Lync Server". Needless to say that this step should be added to your employee leaving procedures to ensure that access is completely disabled.



Check it out for yourself:
  1. Create an Active Directory test user
  2. Enable the account for Lync 
  3. Login to the Lync client with the new test account, making sure not to select the "Save my password" option
  4. Check the Lync Front End security logs and you will see the login event for the user
  5. Under the current users personal certificate store you will see a certificate issued by Lync for the sign-in name:


  6. If you haven't already, install the Lync Resource Kit on your Lync Front End server (see here)
  7. From the Lync Front End server open command prompt and browse to the Lync Resource Kit directory (For Lync 2013 - C:\Program Files\Microsoft Lync Server 2013\ResKit)
  8. Run dbanalyze.exe /report:user /user:<test user UPN> /sqlserver:<FQDN of Lync Server>\RTCLocal
  9. At the bottom of the report there will be information about the certificates that have been issued - Device ID, Publication Time, and Expiration Date. Regardless of whether the "Save my password" option is selected, a server certificate will exist for the user, and user could have more than 1 certificate if they have logged in to multiple PC's:

  10. Run Get-CsClientCertificate <test user> from the Lync Management Shell and you will also see the certificate
  11. Now logoff Lync
  12. Check the Lync Front End security logs and you will see the logoff event for the user
  13. Under the current users personal certificate store you will see that the previously issued certificate has been removed
  14. Run the dbanalyze.exe command again from step 8 and you will see that the certificate still exists on the server
  15. Run Get-CsClientCertificate <test user> from the Lync Management Shell and you will see the certificate still exists on the server
  16. Now this time login to Lync, this time selecting the "Save my password" option. Lync 2013 will prompt you to confirm you want to save your sign-in information


  17. Logoff Lync
  18. Check the Lync Front End security logs and you will notice that login and logoff events are no longer recorded. I can only assume this is because we are now using certificate authentication
  19. Under the current users personal certificate store you will see that the previously issued certificate still exists. This will be used to authenticate the users future login attempts
  20. Now go and disable the AD account
  21. Try and sign-in to Lync and see what happens. Amazingly you're still be able to sign in!!! This will continue to be the case until you delete the client sign-in information or associated client certificate, or run Revoke-CsClientCertificate from the Lync Management Shell. 
  22. Lets delete the AD account and see what happens
  23. Now try and sign-in to Lync and see what happens. Whew we can no longer sign-in!
  24. Run the dbanalyze command in step 8 again. This time you should get the following error - "There was an error communicating with the database:###50010:ReportUserData:test.user1@domain.com is not found in this database"
  25. Run Get-CsClientCertificate <test user> from the Lync Management Shell. This time you will get the following error "Cannot find user in Active Directory"

PowerShell
PowerShell could come to the rescue to simplify the administrative effort when disabling users. You could run one of the following 2 options as a scheduled task, which would ensure that the additional steps are taken to stop disabled users logging in to Lync.

Disable Lync for all users who have a disabled AD account - This is a good option if the users will no be re-enabled at a later date:

Revoke the client certificate for users who have a disabled AD account - This option will revoke the client certificate and ensure the user has to re-authenticate using domain credentials before being able to download a new one:


Lync 2010 April 2014 Updates Released

$
0
0

 Product
 Version
External KB
Lync 2010 (64bit client)
4.0.7577.4445
Lync 2010 (32bit client)
4.0.7577.4445
Lync Server 2010
4.0.7577.230

See full update history for Lync here.


Removing an Exchange 2013 UM Dial Plan

$
0
0
What was a pretty easy task in Exchange 2010, seems to have become more difficult in the new Exchange 2013 Control Panel (ECP). When deleting a UM Dial Plan you need to remove all of its associations first, these are:

UM Mailbox Policies and UM Auto Attendants
Remove any Mailbox Policies or Auto Attendants from the Dial Plan



UM Server
Remove the Dial Plans association to the UM Call Router and UM Service



UM IP gateways/UM Hunt Groups
Remove the Dial Plans association to a UM IP Gateway by deleting the UM Hunt Group bound to the Dial Plan. This is where it gets interesting - The below screen shot shows the UM Hunt Group configuration section in the Dial Plan. The troubles is when you create a SIP URI Dial Plan type which is required for Lync, you cannot see this section. I'm not sure if this is a bug, or by design.


To get around this issue you can use PowerShell, but this leads me to the next issue. The Technet documentation gives the following syntax "Remove-UMHuntGroup -Identity MyUMHuntGroup", however this is not 100% correct. The identity should actually be in the form <Gateway Identity>\<Hunt Group Name>.

  • Gateway Identity is found in the "Name" column returned from Get-UMIPGateway
  • Hunt Group is found in the "Name" column returned from Get-UMHuntGroup


Your command should look something like this:

If you get the syntax wrong you'll probably see one of the following 2 error messages:
>>Cannot process argument transformation on parameter 'Identity'. Cannot convert value "NLNZ Offices:NL NZ Offices Dial
Plan" to type "Microsoft.Exchange.Configuration.Tasks.UMHuntGroupIdParameter". Error: "'NLNZ Offices:NL NZ Offices
Dial Plan' isn't a valid UM hunt group identity. Specify an identity in the form "<gateway identity>\<hunt group
name>"."
    + CategoryInfo          : InvalidData: (:) [Remove-UMHuntGroup], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Remove-UMHuntGroup
    + PSComputerName        : lxlhlyncexch01.lhl.local

>>The operation couldn't be performed because object '<UM Server>\NLNZ Offices' couldn't be found on
'<UM Server>'.
    + CategoryInfo          : NotSpecified: (:) [Remove-UMHuntGroup], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : FAC401B1,Microsoft.Exchange.Management.Tasks.UM.RemoveUMHuntGroup
    + PSComputerName        : <UM Server>

PowerShell
Below is a rough example of how PowerShell could make this task a little easier:


Create Lync UM Contact Objects Automatically

$
0
0
In order for Lync to be able to route calls to Exchange Unified Messaging, contact objects need to be created using the Exchange UM Integration Utility (OcsUmUtil.exe). I have always thought this process is rather clunky and wanted to make the process easier, enter Create-LyncUMContactObjects.

How does it work?
The script queries Exchange for existing Auto-Attendant and Dial Plan pilot numbers. It then searches Active Directory for objects that have a matching Line URI (msRTCSIP-Line). If a match is not found, the contact object will be created.



Instructions
  1. Download Create-LyncUMContactObjects.ps1 from here
  2. Review prerequisites and usage examples below
  3. Run the script
  4. After the script has run you can check OcsUmUtil.exe to make sure the contacts have been created successfully or just run live test

Usage
Create-LyncUMContactObjects -Domain <Domain FQDN> -SIPDomain <SIP Domain> -RegistrarPool <Pool FQDN> -ExchangeServer <FQDN> -OU <OU for contact objects> -SleepTime <optional: Seconds> -CreateAA <optional: $TRUE|$false> -CreateSA <optional: $TRUE|$false>

Parameters
-Domain <Domain FQDN> : Domain FQDN
-SIPDomain <SIP Domain> : SIP domain for contact objects
-RegistrarPool <Pool FQDN> : Lync pool
-ExchangeServer <FQDN> : Exchange server to connect to for PowerShell commands
-OU <Distinguished Name> : OU to create contact objects in
-SleepTime <optional: Seconds> : Delay between contact creation and update of additional properties
-CreateAA <optional: $TRUE|$false> : Create contact objects for Auto-Attendants
-CreateSA <optional: $TRUE|$false> : Create contact objects for Subscriber Access numbers

Example
Create-LyncUMContactObjects -Domain "domain.local" -SIPDomain "sipdomain.co.nz" -RegistrarPool "lyncpool.sipdomain.co.nz" -ExchangeServer <exchange.domain.local> -OU "OU=LyncContactObjects,DC=domain,DC=local" -SleepTime "10" -CreateAA $true-CreateSA $true

Prerequisites
  • Lync 2013 and Exchange 2013 (currently untested on 2010)
  • PowerShell 3.0
  • User account which is a member of CSAdministrator and Exchange Admins (lesser permissions are possible but not tested)
  • PowerShell may need to be "Run As Administrator"

Any feedback, questions or feature requests please feel free to get in touch.


Lync Phone Edition April 2014 Updates Released

$
0
0
For a full list of all Lync client and server updates see http://www.lync.geek.nz/p/lync-updates.html

 Product
 Version
Download
Lync Phone Edition (for Aastra 6721ip and Aastra 6725ip)
4.0.7577.4444
Lync Phone Edition (for HP 4110 and HP 4120)
4.0.7577.4444
Lync Phone Edition (for Polycom CX500, Polycom CX600, and Polycom CX3000)
4.0.7577.4444
Lync Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540
4.0.7577.4444


Bad Experience with 24/7 Hosting

$
0
0
If you are thinking of hosting a web site in New Zealand you've probably come across 24/7 Hosting.

I moved my sites to them a month ago and have had nothing but trouble with their support. I also paid for a service that I did not receive, and after many attempts to make contact, I am yet to receive a response let alone a refund!!

I am not alone either, I suggest having a read of these forums:
http://www.geekzone.co.nz/forums.asp?forumid=86&topicid=142666

http://www.scambusters.co.nz/forum/viewtopic.php?f=9&t=5985&sid=9b8e73de7d2c9bd450b45f14f169a241

http://www.nocowboys.co.nz/businesses/24-7-Hosting

Proceed with caution with these guys.


Moving Users From Lync Online to Lync On-Premises

Viewing all 116 articles
Browse latest View live