First look Azure File System Configuration

Just announced is the Microsoft Azure File System (https://azure.microsoft.com/en-gb/blog/azure-file-storage-now-generally-available/) which allows users to present Azure storage over the SMB protocol, much like what has been used in the enterprise for many years.

Full details can be found in the link above.

Data is stored in the following structure on Azure. Account\Share\Directory\File. 

The Azure File System is build upon the same technology as the existing Azure storage architecture which includes blobs, containers etc. Therefore Azure File System is backed by all of the same SLA's and guarantees for durability, resiliency and availability as you would have come to expect.

In this post I am going to outline the steps required to create a Storage Account with File Share, and how to present that share to an Azure instance. Firstly login to the Azure Preview Portal. The Storage Account must be an ordinary Storage Account, and not one labelled "Classic", depending on when your subscription was first set up will determine if you even have access to Classic VM's and Storage.

If you do not have a Storage Account click the Add button.

Enter a name for the Storage Account, this must be globally unique. Configure the Resource Group and Regional settings to suit your requirements and click Create.

Once the Storage Account has provisioned click on it, and expand Services. You will notice there is now an option for "Files", if your Storage Account is "classic" the option for Files is not present. Click the Files tile.

Click the + File Share button.

Name the File Share, this only has to be unique to your Storage Account. Also give the file share a quota if you want to. Click Create.

Now click on the File Share, and you will be faced with the following options. As per the Azure file structure, the next step is to create a Directory inside of the File Share. Click the + Directory button.

Once the directory is created, you then have the ability to upload files into the directory. 

Now that the Storage Account is configured with a Share, Directory and sample file. You can now map a client device to the SMB Share, at the time of writing the following versions of Windows with the outlined version of the SMB protocol were supported. You can connect certain versions of Linux/Unix to SMB Share, further details can be found in the article above.

In order to authenticate the Azure instance you are using to connect to your SMB Share, you must have the Storage Account access key, you can expose these from the Preview Portal. Copy Key 1 to the clipboard.

cmdkey /add:demotesting.file.core.windows.net /user:demotesting.file.core.windows.net /pass:y/Do/lCNNGkRiqivgtFlX+XXXXXXXXXXXXSbZ6VOuSkpexVGYCRaGa1x0xBaNtg12FzCQaKb/DhQ==

net use Z: \\demotesting.file.core.windows.net\smbshare /u:demotesting y/Do/lCNNGkRiqivgtFlX+Wt9aJ2B2lkRjIXXXXXXXXXXkpexVGYCRaGa1x0xBaNtg12FzCQaKb/DhQ==

Azure VM Active Directory Move NTDS Database Location

When extending an Active Directory to Azure, I stupidly forgot to install the Active Directory Database and Logs on to a dedicated Azure data disk. All of the Active Directory documentation that relates to Azure recommends doing this for integrity purposes

https://azure.microsoft.com/en-gb/documentation/articles/active-directory-new-forest-virtual-machine/

The AD was installed and configured, so I had to gracefully move the DB and Logs files from there default locations. If you have not already installed Active Directory on your Azure VM's, simply change the installation location when you are going through the wizard.

To create a new data disk in Azure for your VM, click the VM in the Preview Portal, and click All Settings.

Click on Disks.

Click the Attach New icon.

Select a Storage Container in which to provision the data disk into, label the disk something descriptive and also set a size. You should probably do some investigation into how big your Active Directory database is before you do this.

Its important Host Caching is set to none. Click Create.

Once the operation to create an attach the new data disk is complete, use Disk Management (or diskpart) to online, initialize and format the disk. Please note, as the Active Directory database requires some special permissions, the disk must be formatted in NTFS.

On a Domain Controller open an Administrative Command Prompt. The following command will stop the AD DS service, please hit Y to confirm that the AD DS service can be stopped along with the other dependent services.

net stop ntds

The following commands (and sub-commands of NTDSUTIL) should move your AD database and logs without any problems. You do not have to pre-create the folder on the new disk.

ntdsutil activate instance ntds file move db to E:\NTDS move logs to E:\NTDS integrity quit shutdown –r –t 1 (optional)

After the reboot the AD files should now be re-homed.

Azure External Load Balancer "Failed to join virtual machine to load balanced set. The operation failed Port 443 is already in use by one of the endpoints in this deployment."

When you try to create an external/public Azure Load Balancer for HTTPS traffic, you recieve "Failed to join virtual machine to load balanced set. The operation failed Port 443 is already in use by one of the endpoints in this deployment. Ensure that the port numbers are unique across endpoints within a deployment."

The key thing to understand here is that "deployment" actually means the Cloud Service, therefore this error is saying another application or service is currently using TCP port 443 within your current Cloud Service.

Problem spotted, if you click on your Cloud Service and review what is listed under Input Endpoints you will probably find there is a VM instance using TCP 443 behind your Cloud Service public IP address.

The best way to fix this (and only from a GUI) is to use the Preview Portal. Click on the VM that is listed under the Cloud Service as using port 443 and click All Settings then Load Balanced Sets.

As you will see I currently have two Load Balanced Sets, one for Internal traffic and one for External traffic. The public load balanced set is causing the issue here for me, the internal LB was created only a few minutes ago to load balance the internal "tier" of ADFS. The external LB is going to point to WAP endpoints on separate VM's.

So I clicked on the Public LB and it was currently using the Cloud Services IP on TCP 443.

After selecting the Public LB you must click Leave to remove the old endpoints from the LB, if this is the last endpoint within an LB the LB will be automatically deleted. As this was a stale LB instance that I had created weeks ago for testing I went ahead and removed it.

Hopefully deleting the load balanced set works first time, I believe some people have experienced problems doing this from the preview portal, and have had to revert to Powershell to complete the operation.

Now lets try re-creating our Public/External Load Balanced Set with the Cloud Service public IP and TCP port 443. Click the VM's you want to provision into the LB set and click All Settings/Load Balanced Sets, in my case this was the first of my WAP servers that were going to be internet facing. 

Click Join.

If you had the same problem as me and you have successfully removed everything that was conflicting the operation should complete successfully.

Azure AD DirSync Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.

You have your Active Directory configured for SSO with Office 365, therefore the DirSync (or whatever it’s called this week) tool configured. All of your user accounts are populated into Azure AD, with the exception of one.

In your environment you have a number of UPN Suffixes for various reasons, the proper object is throwing the following error from the DirSync (FIM 2010 R2) interface “Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.”

On the Connector Space Object Properties page, the error code 0x8023134a DataValidationFailed is also flagged.

This error is logged by DirSync every time the Export Management Agent operation is run, which happens by default every 3 hours. The user account in question recently had it’s UPN Suffixes changed via a full installation of Forefront Identity Manager that is synchronizing identities from Novell eDirectory.

This is a fairly well known issue to Microsoft as they have outlined in this workaround article;

https://support.microsoft.com/en-us/kb/2669550

What they recommend doing is to connect to the Office 365 via PowerShell using Connect-MsolService.

Set-MsolUserPrincipalName –UserPrincipalName user1@oldupn.com –NewUserPrincipalName user1@newupn.com

This command in theory should work, as all it is doing is altering the UPN Suffix, which cannot be done using the Office 365 Web-UI. Unfortunately the gotcha here for me was that the command failed to run, I had to run it twice. Once to change the user account to my .onmicrosoft.com domain, and then again to update the UPN back to one of the internal federated domains.

Set-MsolUserPrincipalName –UserPrincipalName user1@oldupn.com –NewUserPrincipalName user1@domain.onmicrosoft.com

Set-MsolUserPrincipalName –UserPrincipalName user1@oldupn.com –NewUserPrincipalName user1@newupn.com

Once I did this it completely correctly, and I could see the changes from the Web-UI.