About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2016) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


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






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:

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.



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.


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



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.



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.




Maximum Number of names in a SAN Extension

In what is sure to be a long standing record (of sorts) for me (and maybe only me) – I just submitted a CSR to a public provider with 53 domains in the SAN field.  This raised the question:  “how many entries or names can be in that one field?”  I know there has to be some sort of limit. 

Handy Dandy, we had a TMG guy in the room, so we asked him.  While he did not know off the top of his head, he did have an answer in mere minutes (where I had googled for about 10 and found squat).


So, now we know the field is defined by a database, that a Windows PKI CA is limited to 4k of names, and that somewhere around 150 25 character domain names eat up just under 4k.  By extension, we can assume (and we know what that means) that the Public cert providers are following the same RFC and that they will have a similar limit.

How about that?  An answer to a question you did not know you had!



Handy PowerShell Transcript concept

A co-worker of mine put up this blog entry today, I like it.  I too have closed the PowerShell window before I really wanted to.  I use the F7 key, and the up/down arrows, but there is nothing like a literal log, especially when it comes to working up specific elements of a complex (or even brute force) script.  My thanks to Mr. Jaworski to putting this together – his technique works  on every PS install I have tried it on (so far Hot smile).

I modified the instructions Scott lays out, because I don’t like having an unlimited growth file.  I also did not see the point, however well taken, to some of the preliminary setup.  So, I distilled down to one line:

start-transcript "c:\PS log $(get-date -f "yyyy-MM-dd HHmm").txt”

This simple one liner gets you this:


The resulting file looks like this:


Note that the date/time format is in something *I* like, so you might want to change that around a tad.  But all the nice details are there.

Of course, you will need to “stop-transcript” when you get done.



Lync Server 2010 cmdlet help

Things like built-in help files tend to get overlooked. We often work around things; and I like to have a separate reference handy.  In the case of Lync, there is a mass of great information inside of the PowerShell command “get-help.”    However, the amount of data can be daunting.  For my own purposes, I extracted this data and massaged it a bit. There are 546 cmdlets – the Table of Contents runs 18 pages.   The word doc has a clickable contents section, and each cmdlet has a hyperlink to the online content from TechNet.

You can get the document here.

Here is a PDF also for us iPad users.


AdminSDHolder with Exchange and Lync

The adminsdholder function protects certain user accounts inside of AD.  However, that same protection also presents challenges when connecting users to mobile devices, migrating accounts from application system to a new version, or moving accounts to new locations (like upgrading from OCS R2 to Lync).
If you get “access denied” or “Insufficient rights” errors, then you may have bumped up against some built-in protections that are provided by the AdminSDholder AD DS function set.  Simply, every 20 minutes or so, this process goes through and resets rights and permissions on certain accounts in AD.  This will screw up Exchange and Lync migrations because users in specific groups stop inheriting perms from above (they are protected!).  Going in an twiddling one check box fixes the situation, but you need to know where and why.
After reading this excellent blog article by AD DS MVP John Policelli, try this.
Uh oh.  that blog article cannot be found no more!  Try this location instead:

First, make sure your ADUC is set to show advanced features:
Then, take a look at the account that is giving you the error:
locate the user object, select properties | security | advanced, and then tick the check box indicated by balloon #3.
I think that I have seen this issue at least once (literally) in every Lync, OCS, and Exchange project I have worked on in the last 10 years.  The best practice, of course, would never have one of those protected group members with an email account or Lync/OCS account, but we know that is not always practical or enforced.