Lync is attempting to connect to:

Thanks to Elan Shudnow and Bob Wille who helped get to the bottom of this.

The Issue

At a client site the other day, my Lync client pitched the following error:

Now, as you might imagine, the name here does not match what my client was expecting to find.  Clicking on “connect” fails with this error:

Using the “Try Another Server” allows my client to connect normally; closing the error message with the upper right corner red ‘x’ allows my client to connect normally.

What is going on here?  The Lync client does a number of automatic lookups when initiating login so it can locate an appropriate server.  Here we can see my client querying the local DNS to find its’ server, and we can also see the client ASKING for the address for the lyncfrontendvip that is causing this error.

The Question

What is causing this behavior?  Handled correctly, this is not stopping my client from connecting (eventually); however, this is certainly unexpected. So, here is a netmon trace of my client but this time from another location (my hotel).  Note the Lync client is no longer requesting the odd vipname address.

Why is this happening?

As it turns out, my client’s environment/site location is configured for Lync Phone Edition support; this means that DHCP option 120 was created and configured to deliver information necessary for allowing proper Lync Phone operations.  This screen cap shows this DHCP delivery; and here is the vipname being delivered to my Lync client.

What is happening is that the DHCP, configured for Lync Phone support, is delivering (as it should) SIPServer data to the client host machine.  Clearly, Lync client is hardcoded to default to the SIPServer definition address if that DNS query is valid.  Hence, inside my client’s environment, my Lync client was delivered a SIPServer definition, and used it in favor of the expected _sipexternaltls._tcp.domain.com.  When it attached to the defined SIPServer, it then failed to login (duh!) because my account did not exist on that system. Cancelling the dialogue or telling the client to try another server works because Lync then tries the existing returns for _sipexternaltls._tcp.domain.com.

Conclusion

Consultants who are working in a Lync Phone enabled client environment may see this Lync behavior.  However, your regular users who are roaming, visiting THEIR client sites might see this also.  Their solution, if they don’t figure it out for themselves will be to cancel the error dialogue.  Your job will be to explain the whole mess to them.  I hope this helps.

YMMV.

Cross-forest E2010 user moves

The Issue

Recently, I had to migrate/move users from E2003 to E2010 cross-forest.  FIM took care of the basic user objects (MEU’s) in the new forest, so I developed the following.  It would seem that this process, while hinted at in various websites, blogs, and articles, was always sort of vague – and in my case the permissions referenced were not enough to complete the tasks.  The source object modifications failed.  As I was doing the moves with a domain admin/org admin in the target, I had no issues there.

The Solution

csv format

# remember to not have a trailing line feed after the last entry

# - it causes the script to loop on a blank line

# - you can also remove the database field and e2010 will distribute mailboxes automatically among the available databases

---

identity,database

%m@domain.com,databasename

%m@domain.com,databasename

---

Perms needed

# The various texts indicate much less perms (recipient admin and local admin to the server) than I show here.

# These work much better!

Target: Domain Admin and Exchange Org Administrator

Source: Domain Admin and e2003 Full Admin

--- script follows ---

$SourceCredentials = Get-Credential

$TargetCredentials = Get-Credential

set-location "D:\program files\microsoft\exchange server\v14\Scripts"

import-csv d:\migrationcsvfiles\testusers.csv | foreach {.\Prepare-MoveRequest.ps1 -Identity $_.identity -RemoteForestDomainController whateveritis.domain.com -RemoteForestCredential $sourceCredentials -LocalForestDomainController whateveritis.domain.com -LocalForestCredential $targetCredentials -UseLocalObject}

# I noticed some random AD GUID errors when running both lines at once, so I started  the top four lines, then did not copy in the line return after the new-moverequest and things stop erroring. YMMV.

import-csv d:\migrationcsvfiles\testusers.csv | foreach {New-MoveRequest -Identity $_.identity -RemoteLegacy -TargetDatabase $_.database -RemoteGlobalCatalog whateveritis.domain.com -RemoteCredential $sourceCredentials -DomainController whateveritis.domain.com -TargetDeliveryDomain "domain.com"}

---

404 Errors with Successful Exchange 2010 EMC Actions

The Issue

Actions in the EMC such as moving active databases or any command that modifies an object are successful, but complete with a warning message:

Warning:
The cmdlet extension agent with the index 0 has thrown an exception in OnComplete(). The exception is: System.Net.WebException: The request failed with HTTP status 404: Not Found.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.Exchange.SoapWebClient.CustomSoapHttpClientProtocol.<>c__DisplayClass4.<Invoke>b__3()
   at Microsoft.Exchange.SoapWebClient.HttpAuthenticator.NetworkServiceHttpAuthenticator.AuthenticateAndExecute[T](SoapHttpClientProtocol client, AuthenticateAndExecuteHandler`1 handler)
   at Microsoft.Exchange.SoapWebClient.SoapHttpClientAuthenticator.AuthenticateAndExecute[T](SoapHttpClientProtocol client, AuthenticateAndExecuteHandler`1 handler)
   at Microsoft.Exchange.SoapWebClient.EWS.ExchangeServiceBinding.FindFolder(FindFolderType FindFolder1)
   at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.EwsMailer.GetAdminAuditLogsFolder(ADUser adUser)
   at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.EwsMailer..ctor(OrganizationId organizationId, ADUser adUser, ExchangePrincipal principal)
   at Microsoft.Exchange.ProvisioningAgent.MailboxLoggerFactory.Create(OrganizationId organizationId, ADUser mailbox, ExchangePrincipal principal)
   at Microsoft.Exchange.ProvisioningAgent.AdminLogAgentClassFactory.ConfigWrapper.get_MailboxLogger()
   at Microsoft.Exchange.ProvisioningAgent.AdminLogProvisioningHandler.OnComplete(Boolean succeeded, Exception e)
   at Microsoft.Exchange.Provisioning.ProvisioningLayer.OnComplete(Task task, Boolean succeeded, Exception exception)

The Fix (partial)

This is, of course very annoying and looks pretty bad.  After some googling, I found this blog.

While not exactly accurate to my situation (my EWS is configured properly) I figured it could not hurt to try.

Get-AdminAuditLogConfig

Set-AdminAuditLogConfig -AdminAuditLogEnabled $false

These screen caps show that the adminaudit logging was indeed set to the Exchange 2010 SP1 default.; disabling this function makes the error warnings cease and the desired actions are s still successful.  Because my EWS was configured properly, I believe the system is throwing the error because my EWS is already configured to support HLB that does not exist (yet).  I will reverse this command after we deploy the HLB layer to confirm.

YMMV

E2010 EMC cannot read local server

The Issue

Opened the EMC on several E2010 servers today.  Was rudely told that the EMC could not contact the local server.  A reboot fixed the problem, but I don’t like that.

I found this little routine here.

1. make sure IIS WinRM extension is installed
2. open powershell and run command : WinRM Quickconfig
3. Open IIS go to Powershell virtual directory and check that SSL in disabled and authentification is set only to Anonymous
4. Open Windows powershell modules
5. run Remove-PowershellVirtualDirectory command
6. run New-PowershellVirtuallirectory command
7. IISreset

I did not have to do the entire thing in my case.  I did, however, check each and every e2010 (all 14) in the environment.  NONE of them had the WinRM installed.  All of them had the PowerShell vDir with anonymous disabled, but not requiring SSL.

What’s up with that?  I checked the e2010 on server 2008 R2 prerequisites and the IIS WinRM is not listed for any role – which explains why it was not present on any of my servers.

The Fix

So, my final resolution was:

1. Install IIS WinRM Extension
2. Enable Anonymous on the PowerShell vDir

YMMV

Lync on Wireless (Remote user)

The Issue:

I have been having Lync connection issues – as in server drops, random disconnects, bad bad bad. I have done some local troubleshooting, and it appears that I have identified an issue that is very close to the “sun in the IR sensor” that used to shut down/disable HP printers.

The Cause:

It would appear that every time the microwave oven upstairs is running, the entire network drops. Not just the wireless, but the entire thing. This is interesting in that the kitchen is on the far side of the house – at least 80 feet way in a straight line, and upstairs to boot. I am hardwired in to Comcrappy home internet. Wireless is DLink. One difference between this setup and my previous residence is that the microwave is in a cabinet which may be focusing the oven radiation spill at this end of the house.

The Solution:

I don’t have one, yet.

YMMV

Configure DHCP Options to enable sign-in for IP Phones

In this white paper Microsoft  provides details about how to configure DHCP servers from the following manufacturers: BlueCat, Cisco, Linux, Infoblox, and QIP. It extends the information provided in the topic “Configuring DHCP Options on DHCP Servers other than Windows DHCP Server.” The information in this white paper does not apply to DHCP servers that are a component of Windows Server.

Get the guide here.

Monitor OCS and Lync Call Capacity

Tom Pacyk over at ConfusedAmused has a very nice set of scripts to help the Lync/OCS administrator look at the peak call numbers on your Mediation servers.

http://www.confusedamused.com/notebook/monitoring-ocs-and-lync-peak-call-capacity/

YMMV