Recently working with a client on a WVD deployment we ran into an issue where the users profiles were not being created within the FSLogix profile store within an Azure File Share.
Looking in the FSLogix logs (%ProgramData%\FSLogix\Logs\Profile) were were receiveing the following errors
[ERROR:00000005] No Create access: \\STORAGEACCOUNT.file.core.windows.net\SHARE\S-1-5-21-11111111-22222222-11111111-333_Test.User-test (Access is denied.)
We checked FSLogix Agent configuraiton settings within the registry
(HKLM\software\FSLogix\Profiles) and found the required 'VHDLocations' String was configured correctly with the UNC path to the \\storage account\share and the 'Enabled' DWORD with a value of 1
Another place to check for FSLogix error codes is within HKLM\Software\FSLogix\Profiles\Sessions<UserSID>
https://docs.microsoft.com/en-us/fslogix/fslogix-error-codes-reference
This deployment was using traditional On-Prem Active Directrory synchronised with Azure AD using Azure AD Connect and what would be causing the issue.
To get around this we first had to disable Azure Active Directory Domain Service (AAD DS) authentication within the Storage Account. Then go through the process of domain joining the Stoargae Account through by using the following PowerShell as documented at https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable#enable-ad-authentication-for-your-account
Please ensure you carefully ready the prerequisites!
#Change the execution policy to unblock importing AzFilesHybrid.psm1 module
Import-module C:\InstallPoint\AzFilesHybrid\AzFilesHybrid.psm1
Now you can check that the feature is enabled:
Looking in the FSLogix logs (%ProgramData%\FSLogix\Logs\Profile) were were receiveing the following errors
[ERROR:00000005] No Create access: \\STORAGEACCOUNT.file.core.windows.net\SHARE\S-1-5-21-11111111-22222222-11111111-333_Test.User-test (Access is denied.)
We checked FSLogix Agent configuraiton settings within the registry
(HKLM\software\FSLogix\Profiles) and found the required 'VHDLocations' String was configured correctly with the UNC path to the \\storage account\share and the 'Enabled' DWORD with a value of 1
Another place to check for FSLogix error codes is within HKLM\Software\FSLogix\Profiles\Sessions<UserSID>
https://docs.microsoft.com/en-us/fslogix/fslogix-error-codes-reference
We then tried to access the File Sahre just through a UNC using windows explorer and this is when we received the an authenticaiton prompt. This should not happen! You should be able to browse to the share with no authenticaiton promts.
Things to now check:
Firewall and NSG rules are blocking access to the fireshare. You can use IP Flow to verify the connectivity to ensure that the WVD WMs have connectivity to the storage: https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-ip-flow-verify-overview
You can also using the following PowerShell to check contectivity (replacing the appropriate values):
Connect-AzAccount
Set-AzContext -SubscriptionId your-subscription-id
$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"
# This command requires you to be logged into your Azure
account, run Login-AzAccount if you haven't
# already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName
# The ComputerName, or host, is
<storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because
non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for
Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host)
-Port 445
If the connection was successful, you should see the following output:
ComputerName : <storage-account-host-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
At this point everything seemed fine and we was able to establish a connection.
We next checked the authentication configured on the Storage Account within Azure. This is where we noted it was configured to use Azure Active Directory Domain Service (AAD DS)
To get around this we first had to disable Azure Active Directory Domain Service (AAD DS) authentication within the Storage Account. Then go through the process of domain joining the Stoargae Account through by using the following PowerShell as documented at https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable#enable-ad-authentication-for-your-account
Please ensure you carefully ready the prerequisites!
#Change the execution policy to unblock importing AzFilesHybrid.psm1 module
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
Import-module C:\InstallPoint\AzFilesHybrid\AzFilesHybrid.psm1
#Change the execution policy to unblock importing
AzFilesHybrid.psm1 module
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
Install-Module -Name Az.Storage -RequiredVersion 1.11.1-preview -AllowPrerelease
# Navigate to where AzFilesHybrid is unzipped and stored and
run to copy the files into your path
.\CopyToPSPath.ps1
#Import AzFilesHybrid module
Import-Module -Name AzFilesHybrid -Force
#Login with an Azure AD credential that has either storage
account owner or contributer RBAC assignment
Connect-AzAccount
#Select the target subscription for the current session
Select-AzSubscription -SubscriptionId "your-subscription-id "
# Register the target storage account with your active
directory environment under the target OU (for example:
"OU=ComputersOU,DC=prod,DC=corp,DC=contoso,DC=com")
# You can choose to create the identity that represents the
storage account as either a Service Logon Account or Computer Account, depends
on the AD permission you have and preference.
Join-AzStorageAccountForAuth `
-ResourceGroupName "<your-resource-group-name>" `
-Name "<your-storage-account-name>" `
-DomainAccountType "ComputerAccount" `
-OrganizationalUnitName "<your-ou-name>"
Now you can check that the feature is enabled:
# Get the target storage
account
$storageaccount = Get-AzStorageAccount `
-ResourceGroupName "<your-resource-group-name>" `
-Name "<your-storage-account-name>"
# List the directory service of the selected service account
$storageAccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
# List the directory domain information if the storage account
has enabled AD authentication for file shares
$storageAccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties
Following these changes we retested and found the the profiles were being created as expected.
I hope this helps you out!
I hope this helps you out!
Comments
Post a Comment