Testing

I’m going to test some new designs for the page, so the layout might be a bit weird from time to time…

List static routing config

After adding a static route to Lync (for example when adding a CTP integration) you can use the following command to show the route:
 Get-CsStaticRoutingConfiguration Service:Registrar:lspool01.contoso.com
 
Identity : Service:Registrar:lspool01.contoso.com
Route    : {MatchUri=video.contoso.com;MatchOnlyPhoneUri=False;Enabled=True;ReplaceHostInRequestUri=False}

This will list the static route, but it won’t show all the route details (specifically the route target which is semi often used in troubleshooting) as they are contained inside a Route object in the StaticRoutingConfiguration object. To list the details of the route, do:

This will give you the content of the route.

Transport               : TransportChoice=Certificate=Microsoft.Rtc.Management.WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=vcsc.contoso.com;Port=5061
MatchUri                : video.contoso.com
MatchOnlyPhoneUri       : False
Enabled                 : True
ReplaceHostInRequestUri : False

Playing with PS: Script: Start remote Lync management session

I wrote a script to start a remote Lync management shell session based on this post. This of course is a big bloated way to do it (it can be done as a twoliner), but I need the PS training 😛

 ##########################################################################################################################
 # New-RemoteCSPSsession.ps1
 #
 # Opens a remote session to a Lync Management Shell and imports all commands
 #
 # Uses current logged inn credentials, but can optionally supply other credentials.
 #
 # eg.
 # Prompt for fefqdn:
 # .New-RemoteCSPSsession.ps1
 #
 # Use other credential:
 # .New-RemoteCSPSsession.ps1 -othercredential $true
 #
 # Ignore certificates on fe:
 # .New-RemoteCSPSsession.ps1 -notrust $true
 #
 # fefqdn can be passed in arguments as well:
 # .New-RemoteCSPSsession.ps1 -csfe lync-admin.contoso.local
 #
 # Written by Tom-Inge Larsen (www.codesalot.com), based on this blogpost:
 # (http://blogs.technet.com/b/csps/archive/2010/06/16/qsremoteaccess.aspx)
 # this script can also easily be run as a twoliner:
 # (http://blog.powershell.no/2010/12/05/lync-server-2010-remote-administration/)
 #
 # $session = New-PSSession -ConnectionUri https://lync-admin.contoso.local/OcsPowershell -Credential (Get-Credential)
 # Import-PSSession -Session $session
 #
 #
 ##########################################################################################################################
 param($othercredential,$notrust,$csfe)

$env = get-host
 $majorversion = $host.version.major

if ($majorversion -lt 2) {
 write-Host "You need to run at least Powershell 2.0 to run this script. http://support.microsoft.com/kb/968929"
 } else {

if ($csfe -eq $null) {
 $csfe = Read-Host "Please enter the FQDN of the Lync Front End pool you want to connect to"
 }

$connectionURI = "https://"+$csfe+"/OcsPowershell"
 $cmdstring = 'New-PSSession -ConnectionUri $connectionURI'

if ($othercredential -eq $true) {
 $credential = Get-Credential
 $cmdstring += ' -Credential $credential'
 }
 if ($notrust -eq $true) {
 $sessionoption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
 $cmdstring += ' -SessionOption $sessionoption'
 }

$session = & $executioncontext.invokecommand.NewScriptBlock($cmdstring)

Import-PSSession $session
 }

Presence issues with the calendar integration in CU2?

I just had a case where the users experienced that presence in the Lync client did not update based on the calendar information unless they restarted the client completely. Relogging did not help.

The weird thing was that on the users contact card they would be listed as busy, but their presence was still available.

After quite a bit of troubleshooting and some help from colleagues, I ended up removing CU2 (the April 2011 update, gives version .275 to the client). This removed the problem completely. So, if you are having presence issues with Lync, try removing CU2 for now.

This might be a bug?

Lync 2010 and EWS followup

This is a followup to this post.

Turns out that Outlook doesn’t really like autodiscover through SRV records and proceeds to ask the user for authentication when this happens. This is often not a desireable situation.

The other option seemed to be to add names for autodiscover.domain.com for each of the SMTP domains to the certificate on the CAS. We tried this as well, but in this configuration the Lync client started asking about trust of the server. A bit of searching led me to this post by Jens Trier Rasmussen that explains why.

I was not able to find any place to add trusted servers to Lyncs trusted server list, but for Outlook i could, so the solution was to revert to SRV records, and add this regkey to the machines:


Office 2007:
HKCUSoftwareMicrosoftOffice12.0OutlookAutoDiscoverRedirectServers

Office 2010:
HKCUSoftwareMicrosoftOffice14.0OutlookAutoDiscoverRedirectServers

add the CAS server FQDN as the value name of a key with value type REG_SZ and empty value data.

This tells Outlook to always trust this server.

Federate with Lync Online

To federate with Lync Online/Office 365, run:

 New-CSHostingProvider –identity LyncOnline –ProxyFqdn sipfed.online.lync.com –Enabled $True

Enable-CSTopology
 

Here’s how to do it using GUI: http://techietom.co.uk/blog/2011/04/how-to-enable-office365-lync-online-to-federate-with-lync-on-prem/