I’m working with a customer who is migrating from on-premises datacentres to the cloud – using a virtual datacentre in Microsoft Azure. One of the challenges we have is around the size of the volumes on a file server: Azure has a maximum disk size of 1023GB and the existing server has a LUN attached that exceeds this size.
We can use other technologies in Windows to expand volumes over multiple disks (breaking the <1TB limit) but the software we intend to use for the migration (Double Take Move) needs the source and target to match. That means that the large volume needs to be reduced in size, which means moving some of the data to a new volume (at least temporarily).
One of my colleagues moved the data (using a method that retained permissions) but the top level folders that he created were new and only had inherited permissions from their parent. After watching him getting more and more frustrated, manually configuring access control lists and comparing them in the Windows Explorer GUI, I thought there had to be a better way.
A spot of googling turned up some useful information from forums and this is what I did to copy NTFS permissions from the source to the target (thanks to Kalatzis Stefanos for his answer on Server Fault).
First of all, export the permissions from the source folder with the
icacls D:\data /save perms.txt [/t /c]
/c is continue on error;
/t is to work through subfolders too
Then, apply these permissions to the target volume. They can be applied at volume level, because the export includes the file names and an associated ACL (i.e. it only applies to matching files)
icacls D:\ /restore perms.txt
But what if the source and destination folders/files have different names? That’s answered by Scott Chamberlain in another post, which tells me I can just edit my perms.txt file and change the file/folder name before each ACL.
By following this, I was able to export and re-apply permissions on several folders in a few minutes. Definitely a time saver!
Imagine the scenario: you have a virtual machine running in Azure but something’s gone wrong and you don’t have Administrative credentials to log in to Windows. That’s a more common occurrence than you might expect but there is a workaround: in Azure there an option to reset the local administrator password.
Unfortunately, that capability hasn’t been implemented yet in the management portal for Azure Resource Manager but it is available in Microsoft Azure PowerShell.
I found the following commands worked for me (based on a blog post by Dan Patrick), resetting the built-in administrator account for the defined server in the defined Resource Group to be called DisabledAdmin (after which it won’t be disabled any more but after unlocking the server and creating an alternative administrator, the built in account can be disabled again) with a GUID for the password:
$rgName = "Example-Resource-Group"
$vmName = "SERVERxxx"
$extName = "VMAccessAgent"
$userName = "DisabledAdmin"
$password = [guid]::newguid()
$location = "westeurope"
Set-AzureRmVMAccessExtension -ResourceGroupName $rgName -VMName $vmName -Name $extName -UserName $userName -Password $password -Location $location
(of course, you’ll need to take a note of that GUID if you want to log in to the account!).
The VM Access Extension can be called anything you like (the MSDN reference for
Set-AzureRmVMAccessExtension gives more information); however, as noted in the Microsoft Azure documentation (How to reset the Remote Desktop service or its login password in a Windows VM):
“You can reset remote access to your VM by using either
“Both commands add a new named VM access agent to the virtual machine. At any point, a VM can have only a single VM access agent. To set the VM access agent properties successfully, remove the access agent set previously by using either
Remove-AzureRmVMExtension. Starting from Azure PowerShell version 1.2.2, you can avoid this step when using
Set-AzureRmVMExtension with a
-ForceRerun option. When using
-ForceRerun, make sure to use the same name for the VM access agent as set by the previous command.”
So, by using a known name for the VM Access Extension (VMAccessAgent), I can avoid potential issues later.