Wednesday, May 20, 2015

S4B Lesson Learned - ensure you have ample time between FE update and Edge update on any certificates!

One of the risks of being an always on environment that plays with new software with engineers worldwide is that sometimes you have unsuspected outages.

  1. You are in the middle of a Lync to S4B migration with in place upgrades planned.
  2. You update the FE pool (upgrade in S4B topology builder) and run the in place upgrade (IPU thanks to Keif for this TLA)
  3. The associated Lync 2013 Edge pool is upgraded to S4B in topology builder with the paired pool.
  4. You have not yet taken the outage on your edge servers to IPU them.
  5. Any of your certificates expire!!!
 So what would normally be a rapid cert replacement becomes SQL patching and S4B in place


If you try to do certificates in the Lync 2013 deployment wizard you will see this:
"There are no Lync Server certificate requirements for this computer."

On MVP Adam Ball's recommendation, I re-ran step two and watched all Lync 2013 Edge roles uninstall.

Mount your S4B ISO and run setup.  Once you deal with S4B prerequisites and reboot the server, you will eventually hit this error:
"Error encountered: Internal/External: Assigned certificate not found or is untrusted.  Check that the certificate exists in the certificate store, that it is not expired and that the certificate chain is valid." 


The only real choice is to cancel, as you need to deal with certs before services will start.  So launch the Skype for Business Deployment wizard and you will see a warning that says:
"It looks like you started an upgrade using the In-place upgrade tool but it isn't complete.  If you continue to install the upgrade with the Deployment Wizard, it will end the upgrade you already started with the In-place Upgrade tool. 

To resume the In-place upgrade instead, close the Deployment Wizard  by selecting Exit and launch Setup.exe."

Now you can select Step 3: Certificates and choose to reissue the expired certificate.

Another important point, after a successful Edge update you will see the S4B Edge servers have a Windows Fabric service that won't start.  Documented here, no known fix/issue/risk.

Tuesday, May 12, 2015

Azure AD licensing with O365 PowerShell

I won't go into the depths of Azure AD licensing or the powershell licensing as already provided serveral places on the Internet, but I have not seen the Azure AD MSOLAccountSku for the new Azure AD products published much. These are:

Azure Active Directory Basic
Azure Active Directory Premium
Azure Multi Factor Premium

Wednesday, May 06, 2015

Exchange On Premises Script - Build-EXOReceiveConnectorRemoteRange.ps1 - Configure Exchange Online Transport connectors to only allow connections from EXO

If you are a Hybrid organization with Exchange ON Premises and Exchange Online, and you chose to implement centralized Transport to ensure all Internet SMTP traffic went through your on premises, one of the steps has been to update your Hybrid receive connectors to only allow connections from Exchange Online servers and IP addresses as listed here.

After multiple times polling this list and writing a macro in a text editor or in Microsoft Excel, I decided to write a PowerShell script to provide this code by downloading the content live from the above site and parsing it into a PowerShell friendly format for use with set-ReceiveConnector

Build-EXOReceiveConnectorRemoteRange.ps1 - Version 1.0

Does NOT make changes, just converts their web site into the powershell code you would need.  Exchange Management Shell (EMS) is not required!

If this saved you 5 minutes of time, please tweet/share/comment and let me know!

Sunday, May 03, 2015

Reference: Skype for Business Server and Client versions

Skype for Business Server 2015 is the next generation of the Microsoft Lync product line.  Below is a table of the client and server versions of S4B.  This post will be updated over time.


Release Date Version*
Preview Mar 2015 6.0.9305.0
RTM May 2015 6.0.9319.0
*Highest reported across all FE components


Release Date Version
RTM April 2015 15.0.4711.1002
Security Update May 12 2015 15.0.4719.1000

Thursday, April 30, 2015

AADSync - Increase error limit 5000 - stopped-error-limit

Sometimes large orgs have large errors that they need ignored.  By default, Azure AD Sync (the new DirSync) has a limit of 5000 errors before it will cease synchronizing.  Of course, you could also filter the OUs with known errors to not be synchronized, I can still see a use case where you would want known errors to continue reporting without preventing sychronization.

Using the miisclient.exe in AADSync, I was seeing a stopped-error-limit at 5000 errors, and was only getting about two-thirds of the users synchronized.

After IM'ing with a colleague from Microsoft, I had the answer.  Here's a five year old KB article.

I've pasted and updated the content here:
Cause: Certain synchronization activities result in the creation of temporary error conditions that are eventually resolved once the synchronization has had the opportunity to finish running. In environments where extremely large numbers of objects are being processed the number of these errors may exceed the default error limit of 5000 causing the synchronization process to terminate before it has finished processing all objects.

More Information
You can increase the error limit to a sufficient value so that synchronization can finish processing all objects before the error limit is reached. Given the opportunity to finish, the synchronization process will eventually resolve the temporary error conditions. The error limit is configured by adding the ErrorLimit (REG_DWORD) entry to the following registry subkey:

If you are using MIIS / ILM / IIFP

If you are using AADSync

If you are using FIM 2010 or DirSync

The value is an integer in the range of 0-100000.
• Value set to 0 = Error limit set to 100000
• Value in the range of 1-99999 = Error limit set to value
• Value set to 100000 = Error limit set to 100000
• Value set greater than 100000 = Error limit set to 100000
• No key present = Default error limit set to 5000
Note The miiserver service must be restarted after modifying this registry key.

Wednesday, April 29, 2015

PowerShell and testing connectivity with Test-NetConnection

I have been working in IT long enough to see people stick to their old habits begrudgingly, and I had the realization today that one of the ones I was still holding on to was an inherent need for telnet.exe as a troubleshooting tool.

Let's face it, it is compact, a low security risk to have installed, but it having not been included by default on modern Operating Systems has forced me to memorize import-servermanager and add-windowsfeature telnet-client (and before that servermanagercmd -i telnet-client)

The fact that I can iterate those without looking them up is practically a sign that the tool might need a refresh.

Enter Test-NetConnection.   Now, I won't claim to have discovered or wrote it, but I use PowerShell daily and just learned of it today.

It's new since Windows 8.1 and Windows 2012 R2, which came with PowerShell 4.0.

Like I said - nothing new - it's already been called the SuperPing once.

So what can we do with it?

First off, run it alone is a basic Internet connectivity test using just test-netconnection.  This reaches out to a server at Microsoft to see if you are online.  Great to use programatically like this:

if (test-netconnection) { 
    # Download stuff
    } else { 
    # Error about your Internet

You can also use it to check specific connectivity using something like:
Test-NetConnection -ComputerName -Port 5061 -InformationLevel Detailed -Verbose

Some additional tips:
  • -ComputerName can be shortened to -CN
  • -commonport can be used for things like RDP, HTTP, SMB and PING
  • -traceroute can also be used to display hops to a destination, and -hops can be used to specify the maximum hops to be displayed

 As you can see, this gives us a BUNCH of great information:
  1. Multiple DNS records returned (only shown with the Detailed InformationLevel)
  2. Which IP we connected to
  3. And a successful TCP test!
Have to admit, I might be skipping nslookup and telnet in future deployments, and I hope you do too.   If only it could do UDP tests!