Handling SimpleURLs and Reverse Proxy during migration

Leave a reply

I’ve thought about writing this post for a while, as the topic isn’t really covered very well in the Lync 2013 migration documentation. The issue is also only relevant when migrating from Lync 2010 to Lync 2013.

The scenario is this: You are doing a migration from Lync 2010 to Lync 2013. You are following the migration steps provided in the migration documentation, and have planned and prepared your migration, deployed a pilot pool and moved some pilot users to Lync 2013. Internally everything is working as it should,  all modalities are working and conferencing works via the meeting join page using simple urls regardless of which server the user is on.

Now, most of the deployments I do are not large enough that it is needed to use more than one FE pool and for external access one Edge pool and one reverse Proxy. Because of this, most of the conferencing going on is involving external participants. This means that modalities and meeting join needs to be working for the pilots in external scenarios as well. The next step in the migration documentation covers some of this with the deployment of the Edge server. This will handle the peer to peer modalities, but what about the simple URLs?

If you try to reuse the existing reverse proxy rules, you will end up in one of these situations:

  1. You keep the rule as it is, pointing toward the Lync 2010 pool
    If you do this, simple URLs and meeting join will continue working for meetings created by the Lync 2010 users. But if someone external tries to join a meeting created by one of the pilot Lync 2013 users, they will be met with a page saying “Sorry, something went wrong, and we can’t get you into the meeting.” and if you click on “more info” you will get en error saying “Error:Invalid Conference organizer or Conference ID” like this:
    meetingjoinerror
    The Lync 2013 pilot users will also not be able to log in via the mobile client.
  2. You change the rule, pointing it toward the new Lync 2013 pool
    If you do this, everyting will work as it should for the Lync 2013 users. But if someone tries to join a meeting created by one of the Lync 2010 users, they will be met with an ordinary IIS “404 not found” page
    404

Both of these solutions are not really wanted in a normal migration, so what do we do then? The solution is to handle it as a normal multiple pool deployment. This is as it turns out not really well documented in the TechNet library, but on the Request and Configure a Certificate for Your Reverse HTTP Proxy page there is a note saying this:

If your internal deployment consists of more than one Standard Edition server or Front End pool, you must configure web publishing rules for each external web farm FQDN and you will either need a certificate and web listener for each, or you must obtain a certificate whose subject alternative name contains the names used by all of the pools, assign it to a web listener, and share it among multiple web publishing rules.

This means that you will need to deploy a new reverse proxy publishing rule for the new Lync 2013 Pool with a different DNS name for the external services. The rule will also need to use a certificate that contains all the simple URL names in addition to the new name for the external web services and lyncdiscover. This will in most cases create a need for a new public certificate for this new rule.

By doing this Lync is able to redirect the traffic to the webservices between the reverse proxy rules as it does on the inside, and all functionality should be available for both existing Lync 2010 users and the Lync 2013 pilot users.

Lync 2013 Event Error 21054

Leave a reply

All the Lync server 2013 environments I’ve deployed so far is giving Event ID 21054 from LS Address Book Server once a day. It also happens when you run Update-CsAdressBook.

Users are not indexed in the database that should be

Users are not indexed in the database that should be

I wondered what it was, and found it in the release notes for Lync Server 2013. Turns out that the issue can be safely ignored as long as the update is successful. You can also check the replication by running


Debug-csAddressBookReplication -Poolfqdn <Pool FQDN for which the event was generated>

which should give you an output like this:

As long as “Objects not indexed that should be” and “Abandoned Objects” are zero, the database is okay.

Also, if using SCOM, the Key Health Indicator (KHI) “Address Book Users Correctly Indexed” should be turned off for the pool.

Lync Server 2013 release notes:

http://technet.microsoft.com/en-us/library/jj205120.aspx

Script: Create live tiles that changes power scheme

1 Reply

After i got my Surface Pro, I’ve more often than before found myself needing to change between power schemes. On my laptop, I’ll usually set it to “Max performance” and just leave it there, but on the Surface it’s necessary to conserve power a bit more.

I’ve thought about making a live tile to do this, so I wrote a PowerShell script that will create one live tile for each configured powerscheme on the machine and pins it to the start screen. The code is based on a codesample for creating shutdown tiles, and this ScriptingGuy post. The script needs to be run as Administrator. Enjoy!

Download Create-PowerSchemeTiles.zip or copy the sourcecode:


#requires -Version 3.0

#####################################################################################
# Create-PowerSchemeTiles.ps1
#
# Creates live tiles for all configured power schemes on the machine and pins them to
# the start screen.
#
#
# Usage:
# .Create-PowerSchemeTiles.ps1
#
# Written by Tom-Inge Larsen (<a href="http://www.codesalot.com">http://www.codesalot.com</a>)
#
#####################################################################################

Function CreatePowerSchemeTile
{
    Param
    (
        [parameter(Mandatory=$true)][String[]]$SchemeGUID,
        [parameter(Mandatory=$true)][String[]]$SchemeName
    )
Write-Verbose "Creating Windows shutdown tile to Start menu."

#create a new shortcut
$ShortcutPath = "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\" + $SchemeName + ".lnk"
$Shortcut = $WshShell.CreateShortcut($ShortcutPath)
$Shortcut.TargetPath = "$env:SystemRoot\System32\powercfg.exe"
$arguments = "-s " + $SchemeGUID
$Shortcut.Arguments = $arguments
$Shortcut.Save()

#change the default icon of shortcut
$Lnk = $Desktop.ParseName($ShortcutPath)
$LnkPath = $Lnk.GetLink
$LnkPath.SetIconLocation("$env:SystemRoot\System32\ddores.dll",20)
$LnkPath.Save()

#pin application to windows Start menu
$Verbs = $Lnk.Verbs()
Foreach($Verb in $Verbs) {
    If($Verb.Name.Replace("&","") -match "Pin to Start") {
        $Verb.DoIt()
    }
}

If(Test-Path -Path $ShortcutPath) {
    Write-Host "Create" $SchemeName "tile successfully." -ForegroundColor Green
    } Else {
    Write-Host "Failed to create" $SchemeName "tile." -ForegroundColor Red
   }
}

$Shell = New-Object -ComObject Shell.Application
$Desktop = $Shell.NameSpace(0X0)
$WshShell = New-Object -comObject WScript.Shell
$plans = Get-WmiObject -Class win32_powerplan -Namespace root\cimv2\power
$regex = [regex]"{(.*?)}$"
foreach ($plan in $plans) {
    $planGuid = $regex.Match($plan.instanceID.Tostring()).groups[1].value
    $planName = $plan.ElementName.Tostring()
    Write-Debug $planGuid
    Write-Debug $planName
    CreatePowerSchemeTile -SchemeGUID $planGuid -SchemeName $planName
}

Surface Pro and scaling and fuzzy looking desktop apps

1 Reply

After a bit of chasing around San Diego last week during Lyncconf13, I was able to get a hold of a 128GB Surface Pro at the Best Buy in Fashion Valley, and I absolutely love it so far.  The screen is very good and responsive and the Pen is the best stylus I have tried so far. Makes taking notes in OneNote a blast!

But one of the small things that has bugged me a bit is that some desktop programs seem a bit fuzzy, like for instance Spotify and Chrome (Everyone needs a second browser right?) Some of them are also hard to use with your fingers, I had to use the Pen in Chrome for instance. This happens because the Surface is by default set to scale the desktop to 125%, and those apps aren’t handling that. (I’ve seen that some say the surface is scaled to 150%, but mine was/is not. The result should be the same though)

You can resolve this by telling windows not to scale those programs, like I’ve shown below. (Spotify screens are thumbnailed, click them to se full size.)

I’ll be going back to playing with my Surface now!

This is what Spotify looked like before

This is what Spotify looked like before

Right click twice and choose properties

Right click twice and choose properties

On the Compatability tab, check the "Disable display scaling on high DPI settings" option

On the Compatability tab, check the “Disable display scaling on high DPI settings” option

And the result looks much better!
And the result looks much better!

ACE warnings when publishing topology

Leave a reply

Now and then when publishing the topology, I’ve gotten some warnings that just states one or more of these:

Warning: Ace DOMAIN\RTCUniversalGlobalReadOnlyGroup; Allow; ReadProperty; None; None

and also later in the log

Warning: One or more group access control entries (ACEs) are not ready.

This means that not all ACEs are ready after the forest prep, for whatever reason. Just run a

Enable-CsAdForest

which should reset the permissions, and you should be fine.

http://technet.microsoft.com/en-us/library/gg425713(v=ocs.15).aspx

VCS suffers from a Linux kernel bug

Leave a reply

Just got a mail from Cisco regarding a bug in the Linux kernel making some processes on the VCS go haywire and create a heavy CPU load on the box.

The fix is currently to boot the VCS.

The supposed bug is discussed here: http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
UPDATE: Cisco supportforum post

#Lync mobility failing after #CU5

Leave a reply

If mobility is failing after applying CU5 and your symptoms are a 500 internal server error when browsing https://fepool.contoso.com/mcx/mcxservice.svc, try the steps in this blogpost. Seems to be an issue with the web.config file in the mcx folders in IIS after the update. I’ve had this happen with both int and ext web.config.

http://brekkjen.wordpress.com/2012/04/15/lync-mobility-failing-after-cu5