Setting up multiple domain federation with ADFS 2012 and Office 365

Problem

You have an on-prem Active Directory domain with ADFS 2012 configured to use Office 365 services to for messaging services and would like to expand the usage to another domain that is a different tree in the same forest. The task required to do this is quite simple and that is to change the Authentication type for the new domain from Managed to Federated which is what the currently set up domain with O365 mailboxes is configured as:

You attempt to execute the Update-MsolFederatedDomain cmdlet with the -supportmultipledomain switch to change the federation for the currently federated domain to support multiple federated domains but receive the following error:

PS C:\> Update-MsolFederatedDomain -domainname contoso.com

Successfully updated 'contoso.com' domain.

PS C:\> Update-MsolFederatedDomain -domainname contoso.com -supportmulti

pledomain

Update-MsolFederatedDomain : The switch parameter SupportMultipleDomain is not

supported here.

At line:1 char:27

+ Update-MsolFederatedDomain <<<< -domainname contoso.com -supportmult

ipledomain

+ CategoryInfo : InvalidOperation: (:) [Update-MsolFederatedDomai

n], FederationException

+ FullyQualifiedErrorId : MultipleDomainSwitchNotSupported,Microsoft.Onlin

e.Identity.Federation.Powershell.UpdateFederatedDomainCommand

PS C:\>

Solution

What threw me off with this problem was that most articles I found specifies that the Microsoft Office 365 Identity Platform Relaying Party Trust needs to be removed:

… during this process but because the environment I was working in already had production services in use, I decided to test the -supportmultipledomain on the federated domain to ensure it actually existed and the error message:

Update-MsolFederatedDomain : The switch parameter SupportMultipleDomain is not

supported here.

… does not instill much confidence. After scheduling a weekend window for this reconfiguration, I was able to confirm that the cmdlet:

Update-MsolFederatedDomain -domainname contoso.com -supportmultipledomain

… will work once the Microsoft Office 365 Identity Platform Relaying Party Trust is removed:

So to recap, the process should be as follows:

1. Log onto the ADFS server
2. Launch the AD FS administration console
3. Navigate to AD FS > Trust Relationships > Relaying Party Trusts
4. Delete the Microsoft Office 365 Identity Platform entry
5. Launch Windows Azure Active Directory Module for Windows PowerShell
6. Execute the following:
1. Connect-MSOLService
2. Set-MsolADFSContext -Computer <internalADFSserverName>
3. Update-MsolFederatedDomain -DomainName <alreadyFederatedDomainFQDN>
4. Update-MsolFederatedDomain -DomainName <alreadyFederatedDomainFQDN> -SupportMultipleDomain
5. Convert-MsolDomainToFederated -DomainName <newDomaintoBeAddedFQDN> -SupportMultipleDomain
6. Get-MsolDomain

Hope this helps anyone who might be a bit uncertain whether the -SupportMultipleDomain switch would work or not before they delete the Relaying Party Trust.

Citrix NetScaler VPX appliance fails to boot with the error: “can’t load ‘kernel’”

Problem

You’ve recently upgraded a NetScaler VPX appliance to version 11.0.63.16.nc and have been running the upgrade for a few months but noticed that the appliance fails to boot into the kernel after a restart halting at the following:

FreeBSD/x86 bootstrap loader, Revision NS1.2

Loading /boot/defaults/loader.conf

Unable to load a kernel!

\

can’t load ‘kernel’

Type ‘?’ for a list of commands, ‘help’ for more detailed help.

OK

You proceed with a restore of the virtual machine from a backup solution such as Veeam but noticed that all of the backups boot into the same error.

You attempt to try and find the /boot/defaults/loader.conf directory in the disks but it does not appear to exist:

lsdev -v

set currdev=disk1s1b

ls

set currdev=disk1s1d

ls

set currdev=disk1s1e

ls

You are able to locate the /nsconfig directory on one of the disks:

… and able to list the contents with the command ls nsconfig:

… but missing the other directories such as:

1. /var
2. /netscaler

*Reference: http://support.citrix.com/article/CTX200418

Solution

One of the ways to resolve this issue is to either restore from a backed up virtual machine that would actually boot properly or redeploy a new appliance then restore configuration files.  If you do not have either then the following steps can be used in an attempt to bring the appliance back to a bootable state:

Execute lsdev -v to list the available drives:

From the drives listed, we need to find the one that contains the nsinstall directory and in this example, the list is disk1s1e so execute the following to set the context of the prompt to that drive:

set currdev=disk1s1e

Use the ls command to list the directories:

Note the nsinstall directory in the screenshot above. Execute the ls nsinstall/ command to list the contents:

Note that the following 2 directories are listed:

1. 10.5.54.9.nc
2. 11.0.63.16.nc

This appliance was deployed as version 10.5.54.9.nc initially then upgraded several times to version 11.0.63.16.nc and what appears to have happened is that the boot configuration has gone missing.  Execute the commands:

ls 10.5.54.9.nc

ls 11.0.63.16.nc

Note that both directories contain quite a few files. The file we’re interested in is the NetScaler kernel file that is named ns-{version}-{build}.gz. Since both directories contain this file, we’ll attempt to load the newer 11.0.63.16.nc kernel file by executing the following:

unload

load disk1s1e:/nsinstall/11.0.63.16.nc/ns-11.0-63.16

With the kernel successfully loaded, proceed to type boot to boot into the kernel:

With the appliance booted and accessible, if you don’t have a configuration backup, proceed to get it now through the CLI or GUI:

What you’ll notice at this point is that if we attempt to restart the appliance, we’ll encounter the same error message:

can’t load ‘kernel’

… we faced earlier and this is because the boot configuration has been lost.  The next step to ensure that this boot configuration stays persistent is to reinstall the NetScaler binaries by executing the following:

shell

cd /var/nsinstall/

ls

cd 11.0.63.16.nc

./installns

You should now see the installation begin:

Proceed to reboot the appliance once the install has completed:

The appliance should now be able to boot into the OS and operate as it should:

Note that there is a good chance that:

1. The licenses on the appliance will need to be regenerated so log onto the web portal and see if the NetScaler is now labeled as NetScaler VPX (1)
2. SSL Certificates may be missing so they would need to get re-created (the files will still be there)
3. Various NetScaler features may be disabled so they will need to get re-enabled

Unable to launch Citrix XenDesktop 7.8 virtual desktop published through a NetScaler gateway

Problem

You completed deploying a new XenDesktop virtual desktop catalog, publishing it through a StoreFront, then providing access to the StoreFront through a NetScaler gateway:

Clicking on the desktop icon opens the window while the Delivery Controller attempts to launch and broker the session through the NetScaler to the Windows desktop:

The attempt eventually fails with the following error:

Desktop Viewer

The connection to “<VDI Desktop Group Name>” failed with status (1110).

Solution

While there this error could be caused by several configuration issues, one of the more common reasons I’ve come across is if the NetScaler appliance is configured with 2 networks where 1 is connected to an outside DMZ and the other is connected to an inside DMZ (or internal server network).  A common challenge with this type of setup is that the NetScaler’s default gateway is most likely going to be configured to go out to the internet (outside DMZ network) but this gateway usually does not allow the NetScaler to get back into the internal networks.  The error above is thrown because the NetScaler needs to communicate with the actual VDI but is unable to reach it through the internet gateway.  To get around this issue, either create a static route on the NetScaler to use the internal leg’s default gateway to reach the VDI subnet:

… or configure the gateway out through the internet to route traffic back to the internal network.

Import and Export PST to and from mailboxes on Exchange Server 2016

I’ve noticed many of my clients and colleagues have asked the question how to export and import PSTs from mailboxes on Exchange Server 2016 so I thought I’d write this quick blog post to demonstrate a quick way to do it.

Most Exchange administrators are probably familiar with cmdlets such as New-MailboxExportRequest as shown in the following TechNet library:

https://technet.microsoft.com/en-us/library/ff607299(v=exchg.160).aspx

Those who prefer not to use PowerShell cmdlets can actually use the EAC (Exchange Admin Center) to perform the import and export options as well.  To enable this, the first item to do is grant the Mailbox Import Export role to the group that the account you’ll be performing the import/export action with.  For the purpose of this example, I’ll be granting the Organization Management group the permission.

Navigate to permissions –> admin roles

Open up the properties of the group you would like to assign the Mailbox Import Export permissions.

Navigate down to the Roles window and locate the Mailbox Import Export role:

Add the role:

Save the changes:

If you are testing with the account that you are logged in with, log out of the EAC and back in then navigate to recipients –> mailboxes, right click on a user’s mailbox and you should now see the options:

• Import PST
• Export to a PST file