Looking to try out Lync Mobile on Windows Phone 7, but don’t have a Windows Phone? That was my scenario when I needed to troubleshoot a sign-in issue specific to WP7. I figured it would be as easy as firing up the WP7 emulator, but there are a few roadblocks here such as the fact that a WP7 emulator exists, but you can’t access the Marketplace in it. There are some workarounds for that, but even if manage you launch the Marketplace you can’t actually sign in with a Live ID to download anything.

So, Phone7Market to the rescue. This freebie application allows you to download an app from the Marketplace and load it into the emulator. The first thing you’ll need is the Windows Phone 7 emulator so start by downloading and installing the Windows Phone 7 SDK from Microsoft.

Now that you have the SDK installed you can launch the emulator, but as you can see there’s not much you can do with it out of the box:

Next you’ll need to download and install the Phone7Market application in order to load Lync Mobile.

After installing, open the Phone7Market program and search for Lync.

Right-click the Lync 2010 result, select Quick actions, and select Deploy to Emulator.

This should launch your WP7 emulator and you’ll see the Lync 2010 application loaded for you:

Tip: Press Page Up once to enable keyboard entry from the host PC. You should be able to sign-in successfully:

Quick update here for those of you publishing Lync web services with TMG and having trouble with mobile clients:

If you’re following the Mobility load balancing requirements you’ll find that cookie-based persistence is recommended in order to ensure the clients are always directed to the same Front-End server and session. This isn’t an issue for a single FE, but once you start publishing a farm of FEs within TMG you’ll notice the Lync mobile clients can’t sign in. Android clients can for some reason, but WP7 and iPhone cannot.

The issue you’ll face is that while TMG offers you cookie persistence when publishing a web farm, it really only works when the web listener is enabled for forms-based authentication. Since the Lync Web Services cannot be published via FBA the cookie never gets inserted. The end result is that TMG will now round-robin requests between the published farm members and the mobile clients will never sign in due to a ping-pong behavior. You can verify this behavior by draining all Front-End servers from the farm except for one and you’ll see the clients can now sign in.

For a small deployment where a single FE can handle your entire user load I recommend switching your TMG persistence to source IP. All requests will hit a single FE, but the mobile clients can now maintain their session. And if an FE fails TMG will then fail over to the next server in the farm automatically. For the folks where multiple FEs are used more for capacity reasons you’ll need to use something other than TMG for publishing Lync going forward.

Earlier this week I had a project where we were moving the back-end Lync database from a standalone SQL to a clustered instance (pilot to production for Enterprise Voice!), but we ran into an error I haven’t hit before when trying to add the new SQL store to the topology – Topology Builder was failing on the enabling topology step with the error “The directory name is invalid.” As a result the databases and permissions were not even being populated in the new instance.

We checked the usual suspects: firewalls, permissions, etc with no luck. In the end we just used a different machine that had Topology Builder installed and the same topology file published OK. After doing some more research it seems this is a very generic SQL error that can typically be resolved with a reboot (of the server trying to talk to the SQL instance). So if you hit this error I would suggest just using a different machine, or restart the one you’re using.

For environments with only a few Front-End pools applying device updates is a fairly simple process. You run the Import-CsDeviceUpdate cmdlet a few times to cover each phone vendor and you’re done, but I’ve found that once you have a number of pools to update this process becomes incredibly tedious. In order to expedite this I’ve created a simple little PowerShell script which will search the environment for all Front-End pools and upload all the .cab files to each FE.

You can copy this text and save it as a .ps1 file on your Lync server.

Get-CsService -WebServer | Select PoolFQDN | ForEach {
    Import-CsDeviceUpdate -Identity ('WebServer:' + $_.PoolFQDN) -FileName Aastra.cab
    Import-CsDeviceUpdate -Identity ('WebServer:' + $_.PoolFQDN) -FileName HP.cab
    Import-CsDeviceUpdate -Identity ('WebServer:' + $_.PoolFQDN) -FileName Polycom.cab
    Import-CsDeviceUpdate -Identity ('WebServer:' + $_.PoolFQDN) -FileName Tanjay.cab
}

The only actions required from the admin are:

1. Download each of the Lync Phone Edition packages.
2. Extract each UCUpdates.cab files to a single common folder. Rename them as follows: Aastra.cab, HP.cab, Polycom.cab, Tanjay.cab
3. Open the Lync Management Shell, and CD into the folder where the .cab files were extracted.
4. Launch the script.

Not Microsoft related, but I wanted to point out the Linksys E4200 is something to avoid for anyone who uses Apple AirPlay. Bought one a few weeks ago and updated to the latest firmware they offered. Any time I tried to stream audio to more than 2 devices via AirPlay the router would die and need a power cycling. All other features were fine, but I could consistently crash it by trying to stream to a 3rd AirPlay device. It would go totally unresponsive – wouldn’t even reply to a ping from a device physically plugged into it. The AirPlay streaming to my AppleTV was also really choppy and unreliable.

Replaced it tonight with a Belkin N750 and everything seems well.

My latest joy was tracking down a Lync problem where users on just a single pool were seeing the “Limited External Calling” error in their client after signing in. This had been working previously and no changes to the firewalls, certificates, DNS, or servers had taken place. All the usual stuff checked out OK and the logging traces on the client actually looked pretty clean. We saw no errors on the server and all other functionality seemed just fine.

After digging through the server-side traces I finally noticed a few diagnostic messages appearing periodically while looking for MRAS issues (some portions snipped for readability):

LogType: diagnostic
Severity: error
Text: Message expired in the outbound queue before it could be sent
SIP-Start-Line: SERVICE sip:<Edge Internal Pool Name>:5062;grid SIP/2.0
Peer: <Edge Internal Pool Name>:5062

LogType: diagnostic
Severity: warning
Text: Message or one of its headers caused SIP transaction processing error
Result-Code: 0xc3e93f5b SIPPROXY_E_TRANSACTION_TIMEOUT
Data: Transaction Time-out: Type [2] Method [0x40] Call-Id [7d8d76435a474b568f430436e49cfcfd\n] RUri[sip:<SIP URI>;opaque=user:epid:uZWEVFe3nFqIKFtM_NzmFwAA;gruu] From[<SIP URI>;tag=8E780080] To[<SIP URI>;tag=af1b73d16f]

The timeout and expiry messages finally clued me in on the real problem – it turned out the timezone on this server had been flipped incorrectly by an automated process.

After correcting the clock settings and restarting the FE services we found the A/V authentication working properly again. So if everything else looks correct, it may come down to the basics – make sure your clock is set properly.

A fairly frustrating item in any Lync deployment is the fact that you cannot control what drive the Replica service creates its folder and file share on. There is no way to control this during the Lync installation and it seems fairly random as far as I can tell.

In many instances a Lync server will only have a single disk so this isn’t a big issue, but if you are collocating a Monitoring or Archiving role on a SQL cluster node you can run into some serious problems. Since the drive selection is random, you may find the RtcReplicaRoot folder created on a shared cluster disk. This works fine when that node is active, but as soon as the cluster fails over that drive letter becomes inaccessible and the replica’s topology is out-of-date.

In a scenario where you find the folder on the wrong drive you can move it, but it does require a few manual steps. Much of this is a combination of a Technet forum thread and my own experience, but here is the process which worked for me:

1. Stop the Replica service on the node you are changing.
2. Open a command prompt (As Administrator) and use this command to move the content:
   

   xcopy <Old Drive>\RtcReplicaRoot <New Drive>\RtcReplicaRoot /O /X /E /T /H /K

3. Manually unshare the old folder. It does not show in the Computer Management shares snap-in, so you should check the folder properties directly and unshare from there.
4. Take ownership of the old xds-replica folder inside of the old RtcReplicaRoot folder.
5. Delete the old RtcReplicaRoot folder.
6. Share the new xds-replica folder inside of the new RtcReplicaRoot folder.
7. Grant Network Service full control of this share.
8. Grant (Local)\RTC Local Config Replicator full control of this share.
9. Open Regedit and navigate to HKLM\System\CurrentControlSet\Services\REPLICA
10. Modify the drive letter referenced in the ImagePath value to point to the new drive.
11. Start the replica service.
12. Open the Lync ManagementShell and run:
    

    Invoke-CsManagementStoreReplication -ReplicaFQDN <Server FQDN>

13. Restart the Replica service once more and verify your topology status is up-to-date.

Hope this helps. Pretty sure this falls in the unsupported section since this is not documented anywhere.

Sorry for the off topic post, but my company is growing and looking to add another Microsoft UC Consultant to the team. Please reach out to jobs…at…extrateam.com if interested. The full job posting is below.

Microsoft Unified Communications Consultant @ ExtraTeam
We tend to assume success, and for good reason. We’ve built a bleeding edge technology organization from the ground up. Each and every day we receive validation on our immense value to the world in strategizing and deploying the best of the best technology solutions. Our Microsoft practice has more than doubled over the past year and we continue to expand at a breath-taking pace. You will be joining the top Microsoft consulting team in the Bay Area; our team consists of Microsoft Certified Masters, MVP’s, and published authors.

This is high-performanceville and we just can’t wait to have you here.

Standard description to an exceptional opportunity:

This is a fast moving job where you will be working on all the latest technology from Microsoft.

Typical projects you will be working on include designing, deploying and maintaining;

• Exchange 2010 including Unified Messaging
• Lync 2010 with full voice and video integration

Job Responsibilities:

• Designing: Work closely with our customers to assess their needs and design appropriate solutions as well as being an evangelist for ExtraTeam.
• Implementing: You will be part of a high level team responsible for meeting our customers’ implementation, configuration, installation and management needs.
• Troubleshooting: Work closely with customers to resolve networking problems across a wide range of technologies.
• Documenting: Ensure high quality technical documents are produced quickly and accurately.

Our customer base is a very diverse mix including many household names, defense contractors, retail giants, leading pharmaceuticals as well as local government and education.

Although technical expertise is key, your attitude and aptitude will be far more important. We’re looking for someone with a strong desire to learn from the best, as part of our tightly-knit team.

We are a long standing Microsoft Gold Partner as well as a Cisco Gold Partner.

What’s in it for you:

• Strong base salary, quarterly bonus, benefits, 401K, and much more.
• Stable, fun, and team-oriented work environment.
• Opportunity to innovate with the latest tools at your disposal.
• Opportunity to work remotely on select projects
• Opportunity for growth. This is a full-time, permanent position. We’re thinking long term.

Requirements for you to meet your potential:

• Microsoft MCITP certification in Exchange 2010 and/or Lync 2010
• You will need to be able to handle multiple projects concurrently and drive them to completion (yes, we’re very busy)
• Cisco certification would be desirable

There have been a few instances lately where I’ve needed to add a speech language pack to an Exchange Unified Messaging server after a dial plan and auto-attendants have been created. Installing the language pack is no problem, but what you’ll find is that the new language is only available to new dial plans and any objects tied to them. You cannot simply install the pack and then select the language for an existing user or auto-attendant.

Here is an example case where I’ve installed the Portuguese language pack on a server:

But you can see the pack is not available for a dial plan created prior to the installation:

I’m sure the Microsoft answers are either to A – make sure you install the language packs up front, or B – create a new dial plan and auto-attendants, but in my case A was not possible and I had no interest in the effort involved for B.

So, ADSI Edit to the rescue. You can grab the language codes for installed packs from the UM server object properties at CN=<Server Name>, CN=Servers, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups, CN=<Exchange Org Name>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<Forest>, DC=<TLD>. The msExchUMAvailableLanguages attribute will list the languages installed on the server (1033 is US English):

Now, armed with the language code for Portuguese (1046) you can modify the existing dial plan or auto-attendants objects in the UM AutoAttendant or UM DialPlan containers to support this language. The containers for these objects are found within CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups, CN=<Exchange Org Name>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<Forest>, DC=<TLD>. You can add the language as an option by modifying the msExchUMAvailableLanguages attribute to include the new language code. Here I have added it to an existing plan called Brazil:

You can now see this language appear as an option for the dial plan within the Exchange Management Console:

You can use this same method for an auto-attendant, but I would add the language first to the dial plan the auto-attendant is associated with. Obviously using ADSI Edit incorrectly has potential for causing some serious issues. Proceed at your own risk.

With my most recent Lync project I found Topology Builder crashing when I went to try and publish a brand new topology. I started with the basics and verified I had all the correct group membership for my account and that the SQL server was accessible. The server I was publishing from was 2008 R2 SP1 with all the latest patches, but even after a reboot I would get the following MMC crash as soon as I clicked on publish:

Description:
Stopped working

Problem signature:
Problem Event Name: APPCRASH
Application Name: mmc.exe
Application Version: 6.1.7600.16385
Application Timestamp: 4a5bc808
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.17651
Fault Module Timestamp: 4e21213c
Exception Code: e053534f
Exception Offset: 000000000000cacd
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033

In order to troubleshoot errors like this further you can dig in to the log files Topology Builder generates which can be found in the %APPDATA%\Local\Temp folder. I found the real issue by sorting the files in this folder by last modified date which pointed to the Create-CentralMgmtStore log file. Opening this up I noticed the following section:

Installed SQL Server 2005 Backward Compatibility version is 8.05.2312
Connecting to SQL Server on <SQL Server FQDN>
SqlMajorVersion : 10
SqlMinorVersion : 0
SqlBuildNo : 4000
SQL version is acceptable: 10.0.4000.0
Default database data file path is M:
Default database log file path is L:
Error: dbpath must be a fully qualified drive and path, ie c:\sql\db

Notice the final line which points out the database path requires a drive and path. I had been selecting the option to use the SQL database default paths for the CMS and FE pool databases, but these DB paths were simply a drive letter. Since this is considered invalid for Lync I modified the SQL instance default paths to include a folder after the drive letter.

After this change the topology published just fine.