Direct Access Issues after enabling Load Balancing

Recently I have been working on a Direct Access configuration in Load Balanced setup, and I wish to share my experience.

The setup consists of NetScaler and two Windows Server 2012 R2.

As any normal Direct Access installation, you will start by configuring the first Direct Access Server, and that did work just fine. The issues started when Load Balancing was enabled in Direct Access.

When Load Balancing is enabled in Direct Access, the wizard tells that you need to provide a new DIP for the Internal and External interface, as the current configured IP addresses are going to be used for VIP’s – That means the current configured IP addresses are being “moved” to the Netscaler.
When the wizard completes, the Remote session towards the server will end as the Direct Access server are being reconfigured with new IP addresses.

Reconnecting to the new IP address, and the LB Wizards tells “All Good” 🙂
Wuhuu – Enabling of Load Balancing Direct Access wasn’t that hard. 😉

NetScaler configuration was done, and it all showed up as “green” inside NetScaler.

Then it was time to test with some client, even if there was only one Direct Access server configured.

Testing started and from a client side it was all working.
DCA on Windows 7 said “Corporate Connectivity is working” and Windows 10 said “Connected”
– All good.

Looked in Direct Access Console – Remote Client Status.
Hmm, no client was connected and no client had ever been reported…
Strange – Both DA Clients are showing as connected.

Back to the client, and trying to access internal resources.
– No Access !!

TroubleShooting Time:
Started with all known Direct Access troubleshooting tips, but noone worked..
Starting to suspect the server….

I then decided to add the second Direct Access Server to the Load Balanced Cluster.
The second DA Server was added, and both servers showed up av “All Functional” in Direct Access Console.

Back to the client again.
Same status on both clients, but this time one of the clients showed up in Direct Access Console.
– Did that client work ?

Back to the client, and trying ta access internal resources.
– It works 🙂

Reconnected the Direct Access clients several times, and as long as they ended up on the second server it worked.

Additional troubleshooting:

• Changed the Netscaler config, so just the second server was enabled
  • Direct Access clients worked every time
• Changed the Netscaler config, so just the first server was enabled
  • Direct Access cleints did not work.
• Changed the Netscaler config, so both servers was enabled
  • Direct Access clients worked as long as they was assigned to the second server.

Then I decided to remove the first server from the Direct Access Load Balanced Cluster, and reinstall the server.
After the server was reinstalled and added into the Direct Access Load Balanced cluster, both Direct Access Servers stared to work……

Strange…….

Looks like there are some issues with the Direct Access routines when enabling Load Balancing.
It seems like there are something that isn’t completed when the server changes it’s IP Addresses.

My solution was:

• Establish Direct Access on one server
• Enable Load Balancing
• Add second server to Load Balancing
• Remove first server from Load Balancing
  • Reinstall server
• Add the server back to Load Balancing

Maybe this is fixed in Windows Server 2016, but I don’t know..

“The odd call drops” of the Mediation Server

Nice findings in the article – very relevant for all Lync/S4B installations that includes one or more voice gateways.

y0av. With a zero.

I had a very annoying issue lately when an installation of a new gateway resolved in some calls (specifically to US numbers) dropped by the Skype for Business mediation server saying “A call to a PSTN number failed due to non availability of gateways.”

The cause, according to the mediation server, was that “All gateways available for this call are marked as down“, and the resolution, surprisingly, was to “Verify that these gateways are up and can respond to calls.”

It seemed funny, because all other calls were successful, I have not exhausted the available PRI channels I had, the gateway didn’t seem to lose connectivity for a split second and SIP options are accepted and replied to on both ends.

Looking further at the Lync Monitoring Reports, I noticed the following:

Reported by Client
12000; reason=”Routes available for this request but no available gateway…

View original post 564 more words

Missed Call Notification – Not Working…..

Since November 2015 there has been issues with Missed Call Notification from Lync/S4B to Outlook.
There has been written many blogpost about this, but I will here try to summarize how to fix it – Until Microsoft release a permanent fix for the issue.

The following Windows Update’s are relevant for this issue.

• KB3101496
• KB3114351

I have been trying to solve this at several customers, but made a breaktrough today.

I have been searching for KB3101496 – Nothing to find!
Searched in Registry clearly shows that the patch is installed, but it’s not visible in Control Panel

Additional research pointet me in the direction of KB3114351.

Looking for KB3114351 in Control Panel showed that this patch was installed.
Did a Uninstall of this patch, with a following reboot.
After a reboot, the KB3101496 was again visible in Control Panel.
Did a uninstall of this patch as well, following with a reboot.

After a reboot, I checked the “About Skype for Business”, and the version was clearly changed.

Did a test call, and VOILA – Missed Call Notification is restored !

In Short:

• Unistall KB3114351
  • Reboot Computer
• Unistall KB3101496
  • Reboot Computer

I hope this wil help others that has this problem, and that Microsoft will release a patch that fixes this forever…..

iOS 9 and Lync Mobile 2013 Sign-In Issue

Just a Lync Guy

Background:

Today (9/16) Apple released iOS 9 for iPhone/iPad devices which introduce a list of new features and enhancements around security as well.

Issue:

Following users feedback, a sign-in issue was discovered with iOS 9 and Lync 2013 Mobile clients which effect users that have different settings for their region and language one the iOS device, meaning that heir region settings is set to a different language then the iOS language.

For those who have different settings, the following error message would appear:

Workaround:

The current workaround for now is to change the iOS language to the match the region settings (or vice-versa) until Microsoft will address the issues with upcoming update or with the next SfB Mobile client version.

Additional Information:

• Microsoft also released a KB article describing the problem
• A great blog describing the root cause analysis you can find here
• Another great blog post from Mika (

View original post 10 more words

Establish ADFS in Azure with Azure AD Connect

Recently I have been working to establish Azure AD Connect in Azure, using the GA version of Azure AD Connect. This should be a straight forward, but I encountered some glitches and errors…. This article might help others facing the same issues a faster way to success 🙂 The following infrastructure was established:

• Site-2-Site VPN
• Separate subnet for Azure Services
• Azure added as a site in OnPrem AD Sites and Services
• Servers in Azure
  • Active Directory Domain Controllers
  • ADFS Servers
  • WAP Servers
  • AAD Server

Once all prereq was established, the installation and configurration of AAD Connect could be started. AAD Connect will install, when not using Express Mode, ADFS, ADFS Proxy and DirSync. Installation of AAD Connect was pretty straight forward and the configuration was nicely done, once all information was entered.

Required info was added, and the AAD Connect installation configured ADFS, ADFS Proxy and DirSync. Once installation was complete the DirSync service kicks off and started syncronizing useraccounts…

Error Message on Office 365 Logon:
“Sorry, but we’re having trouble signing you in and 80041034 error messages when a federated user tries to sign in to Office 365”

Bing or Google this error wasn’t giving me a solution to the problem so I went on digging into this. I read a bunch of articles and was about to go into completely removal of AAD Connect – Didn’t actually looking forward to this.

Relevant article at this stage:
– https://support.microsoft.com/en-us/kb/2962537

Then I got into checking where the error occured, since ADFS actually is a 2-party infrastructure.
I asked my self the following questions:

• Is ADFS working ?
• If ADFS is working, does the connection to Office 365 work ?

First thing first – Validate ADFS functionality:

• Test ADFS logon only.
  • Check the followin Url: https://”public name of ADFS”/adfs/ls/IdpInitiatedSignon.aspx
    • Try logon with a account valid for ADFS logon.
      • If logon is OK, then ADFS is OK.

Since ADFS SignOn worked OK – Over to next stage – Office 365 SignOn.

• Used “Microsoft Remote Connectivity Analyzer” – http://aka.ms/rca
  • Test Office 365 Logon.
    • Test failed with information about the token is missing information….

How is this possible, how can the token created by ADFS be missing information when ADFS logon works ?
– New Bing and Google sessions without any clear indication on how to recover from this error…

Getting back to ADFS again – something must be wrong, but WHAT ??

Discovery….
Found on article telling about “How to update or repair the settings of a federated domain in Office 365”
– https://support.microsoft.com/en-us/kb/2647048
Down in this article I found a “Warning” – This might be interesting..

1. Run the steps in the “How to update the federated domain configuration” section earlier in this article to make sure that the update-MSOLFederatedDomain cmdlet finished successfully.
   • If the cmdlet did not finish successfully, do not continue with this procedure. Instead, see the “Known issues that you may encounter when you update or repair a federated domain” section later in this article to troubleshoot the issue.
   • If the cmdlet finishes successfully, leave the Command Prompt window open for later use.
2. Log on to the AD FS server. To do this, click Start, point to All Programs, point to Administrative Tools, and then click AD FS (2.0) Management.
3. In the left navigation pane, click AD FS (2.0), click Trust Relationships, and then click Relying Party Trusts.
4. In the rightmost pane, delete the Microsoft Office 365 Identity Platform entry.
5. In the Windows PowerShell window that you opened in step 1, re-create the deleted trust object. To do this, run the following command, and then press Enter:

6. Update-MSOLFederatedDomain -DomainName <Federated Domain Name>

   or

   Update-MSOLFederatedDomain –DomainName:<Federated Domain Name> –supportmultipledomains

   Notes
   

   Using the –supportmultipledomains switch is required when multiple top-level domains are federated by using the same AD FS federation service.

After these routines was done – I managed to successfully Authenticate towards Office 365, using ADFS in Azure..

Microsoft Ignite 2015 – A travelers story…

Hi all.

In the beginning of May 2015, there was finally time for the first ever Microsoft Ignite conference in Chicago. The time up in front of this was long, but nevertheless full of anticipation on what would Microsoft would bring to the table and out into the air…

I did arrive in Chicago late Sunday afternoon, and was ready to begin the Ignite journey – keynote was first on the agenda. The keynote was fun, interesting and full of new information of what Microsoft was aiming for in the near, and far future…. The keynote was long, from 09:00 to 11:45 – full of thoughts and innovative ideas. After the keynote I was even more exited, of what the following week could offer.

My primary goals for attending Microsoft Ignite, was to get more information about Skype for Business, in both OnPrem, Hybrid and Office365 configuration.

There was a busy week in Chicago, but a very good one. A lot of insight into Microsoft “view” into the future.

A lot of focus is on running hybrid configurations in the combination with Azure.

The trip from Norway to Chicago was definitely worth it, and I am already utilizing much of the stuff I learned during MS Ignite. 

After a fantastic week in Chicago, the time for getting back to Norway started on Friday afternoons. During the layover at O’Hare, Chicago was struck by a thunderstorm. This caused O’Hare to go into Ground Stop, and again delaying the flight by two hours…

Nevertheless I wish to come back next year for a even bigger MS Ignite. 

Skype for Business – Here comes the future

During sessions at #MSIgnite we have heared and seen enough to tell that Skype for Business will bring the future of communication to the marked.

Skype for Business brings great new features to both the end user and to the admins. 

End users will get a much better experience with the new client and clients – richer user interface and more server functions that brings the experience more unified. 

Admins will get a much more robust and stable system, able to bring much more functionality to the end user and several new features and toolsets to better administer and troubleshooting.

I’m now really looking forward to helping all my customers to bring their Lync systems towards Skype for Business.

Thanks Microsoft!

OneLiner: Move Lync users to another Lync pool, based on AD Group

Hi.

The following PS OneLiner move users to another pool, based on AD Group.

Get-ADGroup “AD GroupName” | Get-ADGroupMember -Recursive | ForEach-Object {Move-CsUser $_.SamAccountName -MoveConferenceData -Target “New Lync Pool FQDN” -Confirm:$false}

This might come in handy, when you need to move users based on AD Groups.

Thanks to Joakim Erdal in Atea, for helping with command sequence..

Lync 2013 Mobility and IIS ARR

Since MS TMG server was withdrawn from the marked, IIS ARR has become the most common solution to publish Lync, Exchange and Sharepoint solutions.

There are good guides on how to configure IIS ARR and hos to publish Lync 2013.

One thing that I have been noticing, is that mobile users have been complaining about the following Message: “Your server configuration has changed. Please restart Lync”

After some searching on the topic, there was some info that told us to increase the Proxy Timeout value.
One very important info is:

You will need to increase the Proxy Timeout value for the Web External Publishing Rule.

I have had success with increasing the value to 960 Seconds.

Lync Server 2013 on Windows Server 2012 R2

Hi.
As you all probably know, Lync Server 2013 is fully supported on Windows Server 2012 R2.
To gain Lync Server 2013 Support on Windows Server 2012 R2, Update Lync 2013 With the latest CU.

One very important change is to alter the TLS mechanism in Windows Server 2012 R2.
Windows Server 2012 R2 has changed how the TLS sessions are being cached, and this doesn’t work well with Lync 2013.
The following article describes a required registry modification:
– http://support.microsoft.com/kb/2901554/en-us

As the article describes – “Lync Server 2013 is supported by Windows Server 2012 R2 when this registry workaround is performed.”

Continue to Lync – Happy Lync’ing 😉