Convert-MSOLDomainToFederated: Service not available

AAAAAAH….this is not a typical reaction I have when setting up things, but this one was driving me nuts. Let me explain…

Story so far…

I was asked to help a company with the implementation of Single Sign-on (SSO) between their on-premises environment and Office 365. During the installation and configuration phase of the ADFS 2.0 servers we ran into an error that drove me nuts. This process should be fairly easy. To help you through this process of deploying SSO, there are tons of guides to be found on the interwebs to set up SSO for your Office 365 services. Just check it out. I like this one in particular.In short: to create a federated connection with Office 365 in the cloud you have to do a couple of things:

  • Get an Enterprise CA Certificate
  • Configure Office 365
  • Install and configure ADFS 2.0
  • Install and configure DirSync

After the setup of ADFS 2.0 you will come across the Microsoft Online Services and connecting to them and then converting your registered Office 365 domain to a federated domain;

Keep in mind:I’m doing this from the ADFS server itself, so no need for the Set-MsolADFSContext –Computer cmdlet.Note:I’m using another DNS domain name in the commands below to protect the innocent. Winking smile

First Connecting:

Connect-MSOLService
Then the update cmdlet:
Update-MSOLFederatedDomain -DomainName contosogirls.com -SupportMultipleDomain

The Problem

When everything goes well, no output will be generated. But in this case it gave me the following output:
Convert-MsolDomainToFederated -DomainName contosogirls.com -SupportMultipleDomain

Convert-MsolDomainToFederated : Service not available

At line:1 char:30+ Convert-MsolDomainToFederated <<<<  -DomainName conotosogirls.com -supportMultipleDomain

+ CategoryInfo          : InvalidOperation: (:) [Convert-MsolDomainToFederated], FederationException

+ FullyQualifiedErrorId : InternalError,Microsoft.Online.Identity.Federation.Powershell.ConvertDomainToFederated

Since I was not the one who configured the Office 365 domain and there seemed to be a problem with the Office 365 authentication service, I assumed there was a problem with the services. I tried again after the weekend and was surprised to get the same result. So I guess it’s true what they say about assuming things.

Note:You can check the status of Office 365 services when you log into the Office 365 admin center

After checking everything, and I mean going over the entire installation up until the error, I still could not find any reason for this not to work. So I called Microsoft. The technician went over the process and after consulting with his colleagues a couple of times, came up with the suggestion of checking the account settings of the account we used to login into Office 365 with the Connect-MSOLService cmdlet. Explicitly we needed to check the password expiration policy.

Solution

After the suggestion to set the value for Days before passwords expire: to 90 instead of 730 running the Update-MSOLFederatedDomain cmdlet gave no trouble whatsoever. Setting up DirSync went like a breeze and Single Sign On is actually quite sexy…

Keep in mind:I was not the one who configured Office 365 for this scenario or thought these settings were a good idea 

Concluding

It’s strange the password expiration policy affects converting a domain and the PowerShell output is cryptic. I hope this helps in case you run into the same situation I did. This is how I did it…

No, my Win-X menu doesn’t work

With the installation of Windows 8 there comes an end to the ‘classic’ start menu era. Off course you can put all the programs you want on the start screen. However, things like the control panel, command prompt or the computer management snap-in might be things you want to access easier and quicker. Fortunately for us power users there is another way.How it should look

Windows 8 comes loaded with predefined hotkey combinations. The windows key plays a huge role in these hotkey combinations.

One of these combinations might just be the most useful of all. Win + X. This will bring up a menu with the most used Control Panel and administration tools. You can also reach it by right clicking in the bottom-left corner of your screen. In windows 8 missing the start menu can be annoying if you need to get to these features often, but with this menu it is really easy. You can also reach it by right clicking in the bottom-left corner of your screen.

 

The shortcuts in this menu are in a folder inside the user profile:

C:\Users\%username%\AppData\Local\Microsoft\Windows\WinX

Inside you will default find three group folders corresponding with the groups, separated by lines in the Win+X menu.

A couple of months ago I migrated my work laptop to Windows 8 Enterprise. As I already had played around with it, a lot, not a lot of new things to discover there. So, as any It-Pro would do with a new operating system I went for the Control Panel to customize to my preferred settings

Right click in lower left-hand corner and….nothing happened. I tried again to no avail. Pressing the Windows-key and X at the same time (hence the name: Win-X Menu) did not bring up the menu either.

When I Checked the location mentioned above I noticed that there where no folders present. This can be due to a profile migrated from a previous version of windows or something with a mandatory profile in where the files are not present.To solve this,
just copy the files from a computer with a working Win-X Menu into the folder mentioned above and you should be good to go. You might want to restart after you put the files in the correct location. Inside there should be folders and within those
the correct shortcuts. The images show how they should look.
image
image
image
image

if you want to modify the menu there are other blogs written about that.

DirTeam bloggers at TechEd Europe 2013

From Monday June 24 2013 to Friday June 28 2013, Microsoft organizes TechEd Europe at the Feria Internacional de Madrid (IFEMA) in Madrid, Spain. With a much warmer climate than Amsterdam (TechEd Europe 2012) and Berling (TechEd Europe 2009 and TechEd Europe 2010) and Microsofts convenient repositioning of this event in June, this event should be packed with IT Pros and Developers from across Europe.

To represent the DirTeam.com / ActiveDir.org Weblogs at TechEd Europe, I will be present with fellow blogger Sander Berkouwer and OGD colleague Maarten de Vreeze.

We will be staying in the AC Hotel Madrid Feria by Marriott on Via de los Poblados, just a few blocks from the convention center.

Our flight in from Amsterdam Schiphol Airport (AMS) leaves late Saturday afternoon June 22, and we will be making a short stop in Paris (CDG) on our way to Madrid Barajas Airport(MAD). On our way back we will again be making a short stop in Paris (CDG) on Saturday evening and arriving at Amsterdam Schiphol Airport (AMS) late, in what we hope would be a similar temperature as Madrid…

Madrid

We’re looking forward to TechEd and to seeing you there!

Backing up a Threat Management Gateway using Backup Exec

Everyone can have some trouble using Backup Exec to backup their Threat Management Gateway 2010. TMG uses a different range of dynamic ports from the standard Windows Server installations.

Since Windows Vista the new default start port is 49152. The default end port is 65535. Earlier versions of Windows used 1025 through 5000. The new range gives you 16384 ports. You can Check this with the netsh command.

  • netsh int ipv4 show dynamicport tcp
  • netsh int ipv4 show dynamicport udp
  • netsh int ipv6 show dynamicport tcp
  • netsh int ipv6 show dynamicport udp

image

Now when you execute the command on a machine running TMG 2010 you’ll probably find that the start port is 10000. This can cause problems with Backup Exec.

Backup Exec’s remote Agent uses the Network Data Management Protocol. This necessary to create the backup data stream. The NDMP utilizes port 10000 . Normally this is not an issue. On a TMG however the dynamic range is changed and wininit.exe will seize the first of the Dynamic ports. There are two solutions to this problem.

you can change the port the backup agent uses

Open Notepad in administrator mode and open c:\windows\system32\drivers\etc\services

add the following line to services

  • ndmp 9000/tcp #Network Data Management Protocol

This will change the port to 9000. Don’t forget that you’ll have to do this on the media server as well, and thus on every server you want to back up. Sounds like fun when you have +100 server.

You can change the Dynamic Port Range on your Threat Management Gateway

On your TMG open an elevated command prompt and run the following command:

  • netsh int ipv4 set dynamicportrange tcp startport=10010 numberofports=30000

Now reboot the TMG server

this will free up the first 10 ports of the dynamic range so that NDMP can make use of it. Reboot and make a test run. Beats reconfiguring +100 servers.

You can verify after the reboot if everything went well. If you execute the following command

  • netstat -ao |find /i “listening”

This will give you a listing of the listening ports and the corresponding Process ID. You’ll should find 0.0.0.0:10000 listened to by a process ID that should be the same ID as the Beremote.exe process as obtainable through the Windows Task Manager

image

image

TMG Compression broke my site

Microsoft Threat Management Gateway (TMG) should make publishing websites easy. Generally it is. We had a configuration as shown below:

Drawing2

This should work like a charm. Unfortunately it did not in Internet Explorer 9. Upon testing the published site we noticed that some of the SharePoint functionality was not working as intended; Menu functions were not correctly created in the published page. If you visited through an InPrivate session the problem disappeared. Other browsers, such as Chrome and Firefox did not seem to suffer. Also the situation was a little more complicated:

Drawing3

When we connected from to the published site from the webserver, there was no problem. When we modified the hosts file to bypass the TMG there was no problem. So it seems that the TMG was altering something. And it did.

Since the bulk of the users was connected through a satellite connection which had narrow bandwidth we used some compression methods on the webserver.

Upon testing extensively we determined that the default.css remained empty. This clearly was a caching problem resulting from the TMG configuration.

Eventually we narrowed it down to the Web access policy and the Web Compression Filter on the TMG. turning those off made the problem disappear on the clients.

Since we wanted the Compression Filter to work for some of the websites we had to come up with another solution than simply disabling the filter. After some searching we came across a MSDN article describing the SendAcceptEncodingHeader. The VBscript below can be run on the TMG. It sets the SendAcceptEncodingHeader property to true for a specific publishing rule on the TMG. This will allow compressed content from the webserver to reach the clients correctly.


' Define the constants needed const Error_FileNotFound = &H80070002 Const fpcPolicyWebPublishing = 2 Main(WScript.Arguments) Sub Main(args) If(args.Count = 1) Then AllowCompressedContent args(0) Else Usage() End If End Sub Sub AllowCompressedContent(ruleName) ' Create the root object. Dim root ' The FPCLib.FPC root object Set root = CreateObject("FPC.Root") ' Declare the other objects needed. Dim isaArray ' An FPCArray object Dim rule ' An FPCPolicyRule object ' Get a reference to the array object. Set isaArray = root.GetContainingArray() ' Get a reference to the policy rule specified. On Error Resume Next Set rule = isaArray.ArrayPolicy.PolicyRules.Item(ruleName) If Err.Number = Error_FileNotFound Then WScript.Echo "The policy rule specified could not be found." Else Err.Clear On Error GoTo 0 If rule.Type = fpcPolicyWebPublishing Then If rule.WebPublishingProperties.SendAcceptEncodingHeader = False _ Then rule.WebPublishingProperties.SendAcceptEncodingHeader = True rule.Save WScript.Echo "Done!" Else WScript.Echo "The policy rule specified already " & _ "allows forwarding of compressed content." End If Else WScript.Echo "The policy rule specified is not a Web publishing rule." End If End If End Sub Sub Usage() WScript.Echo "Usage:" & VbCrLf _ & " " & WScript.ScriptName & " RuleName" & VbCrLf _ & "" & VbCrLf _ & " RuleName - Name of the Web publishing rule" WScript.Quit End Sub

By default a web publishing rule instructs the TMG to delete all Accept-Encoding headers sent to the webserver. However the webserver answers with compressed responses. The TMG in turn will not forward the compressed responses. That’s when, for instance, the piece of java that makes up your SharePoint menu items brakes.

Conclusion

Let me point out that this will not be an issue when you are not using compression on the webserver. If you do however, and do not want to turn off all of the compression on TMG then you might find the script helpful.

I’d like to see this property of a web publishing rule to be an option in the GUI. In my opinion, especially considering the fact that a lot of clients, including mobile devices, benefit from compression, this would be a nice option which should be more accessible. Maybe a checkbox in the publishing rule wizard or properties.

How not to create redundancy in your Exchange

When I was at a client the other day I encountered the following:

Tekening1

As you can see the Exchange environment in itself already contains a single point of failure. Namely the Exchange-01 server who solemnly functions as a client access and transport hub. The two database servers however are both made high available through the use of the failover-cluster feature introduced in Windows server 2008. This in itself is a good idea. Beside the fact that this way you can create redundancy within your database hosts this also allows you to  use multiple redundant databases on both servers in a database availability group. You can even reboot one in the middle of production. For instance to  update some compromised certificates. The production reboot should notify clients to restart their outlook, but hey, your exchange is safe and up to date again.

It is a bad idea to install this failover cluster on a failover VMware cluster. The problem arises when an actual failover needs to take place. In a perfect world (where you wouldn’t even need failover since your servers would never break) failover would happen automatically if one server for whatever reason stops functioning. In the case of my client something very interesting happens.

First the database is going to be transferred to the other exchange server. All is well. At the same time, VMware steps in and fails over the Exchange server to another host or whatever it is that VMware does to keep guests alive and restores the system to it’s previous state. So the server that went down is restored with database connection while the windows failover-cluster transferred database access to the other exchange database server. With both servers wanting to access the database neither will be able to and that’s when your exchange database failover-cluster fails. This usually results in a lot of people calling the helpdesk to ask why they can’t access their mail.

This is not due to the fact that either VMware or Failover-clustering is a poor feature, this is because someone implemented a solution without proper testing.

So if you want to make Exchange redundant, only use one method and not two or more stacked methods or it will come around to byte you like an attack dog.

Upgrading SQL

When upgrading your environment to squeaky clean Windows Server 2008 R2 installations sooner or later you will have to tackle the SQL server. Migrating a Microsoft SQL server from 2005 to, say, 2008 R2 should be a walk in the park. It should be, if no one is actually using the server. Unfortunately this won’t be the case. Why buy a license to a product you’re not going to use, right?

So, first and foremost determine a maintenance window. Make sure people are not going to get mad and if they do, well, it’s always nice to be able to point out the fact that you notified them in advance.

First of all, and you can do this in advance, make sure you can run the databases on a different server while upgrading one. Ideally this would be a virtual server, but any domain member server would do. If you install the latest version of SQL Server you can also test if your databases are going to work or if they are going to screw things up. Usually databases that make use of Active Directory service account tend to be pretty easy to migrate.

The KB article describes how to do the standard SharePoint and IIS SQL databases migration:

http://support.microsoft.com/kb/314546

Assuming this all works fine and the databases of, for example, E-Policy Orchestrator are recovered from backup, as well after the migration and everything is running on your temporary server there is something you would like to keep in mind when migration to a virtual temporary server. If you are going to do the migration in the course of a couple of days, you want to add the SQL databases to you backup schedule, in case anything goes wrong. Consider the fact that the truncate of the logs can only complete after a Full backup. If you do any sort of other backup in between this won’t work, your logs will grow and the disk where you keep your logs stored might run out of available space. This basically means you database stops functioning.

This especially goes for virtual machines which usually get backed up with the host during a backup cycle. Make sure the Full Backup of the databases starts after the backup from the host server and guests and truncating the logs should be good.

As you are probably aware it’s best practice to install the databases on a separate disk on the server. Also if you have space to spare, and it is a good idea to use a disc large enough for your collection of precious databases, consider formatting the disc with 64Kb cluster size. This means you will get better performance at the cost of wasting some disc space.

http://msdn.microsoft.com/en-us/library/dd425070.aspx

So you’ve installed and configured the Server, correctly formatted the discs and installed Microsoft SQL Server. First of all, on your clean installation, don’t forget to configure the Windows Firewall. You should have TCP/IP port 1433 (default) open for incoming and outgoing Database traffic.

You now can migrate the databases back. Probably most will work. Then there is the one weird application which brakes. There always is one. Usually there are 3 possible explanations for this:

  • Either the service account is not correctly configured and this usually is a security issue. The applications documentation should help with this.
  • Then there are the applications that work with SQL based accounts and logins. Make sure the database is in mixed mode. With a new SQL server installation those that don’t work probably have lost their principal name in the master database and therefore, don’t work. These applications might have log files which can tell you more about the error you’re encountering. If the principal names are lost you might want to consider restoring them from a backup. What also works is deleting the accounts from the databases you’ve migrated and create new SQL account logins with the same credentials. Make sure these accounts get the appropriate rights in their databases. Most of the time owner will do. Sometimes these applications make use of different than normal or dbo schema’s so also make sure to apply the correct schema to the logins.
  • Third there are the applications you either will have to install from scratch or call in support…there is only so much you can do.

Concluding

Migrating SQL can be hazardous because a lot of services might depend on it. If you draw up a plan, make sure the backup is standby, then little can go wrong. Business critical applications should be extra taken care of.