Azure Files で DFS 名前空間を使用する方法

適用対象: ✔️ SMB ファイル共有

分散ファイルシステム名前空間(Distributed File Systems Namespaces、一般にDFSネームスペースまたはDFS-Nと呼ばれる)は、本番環境でのSMBファイル共有の展開と保守を簡素化するWindows Serverサーバーの役割です。 DFSネームスペースはストレージネームスペース仮想化を提供し、ファイル共有のUNCパスと実際のファイル共有の間に間接的なレイヤーを提供できます。 DFS 名前空間は SMB ファイル共有で動作します。これらのファイル共有がホストされている場所に依存しません。 Azure File Syncの有無にかかわらず、オンプレミスのWindowsファイルサーバー上でホストされるSMB共有、Azureのファイル共有、Azure NetApp Filesや他のサードパーティ製品でホストされるSMBファイル共有、さらには他のクラウドでホストされているファイル共有でも利用できます。

DFSネームスペースの核として、 \\contoso\shares\ProjectXのようなユーザーフレンドリーなUNCパスと、 \\Server01-Prod\ProjectX や \\storageaccount.file.core.windows.net\projectxのようなSMBシェアの基盤となるUNCパスとのマッピングを提供します。 エンドユーザーがファイル共有に移動すると、使いやすいUNCパスを入力しますが、SMBクライアントはマッピングの基盤となるSMBパスにアクセスします。 また、この概念は、\\MyServer\ProjectX のような既存のファイル サーバー名を引き継ぐ場合にも適用できます。 この機能を使用して、次のシナリオを実現できます。

• データの論理セットに対して、移行に強い名前を提供します。 たとえば、 \\contoso\shares\Engineering を \\OldServer\Engineeringにマップできます。 Azure Filesへの移行を完了すると、マッピングを\\storageaccount.file.core.windows.net\engineeringに変更でき、エンドユーザーが使いやすいUNCパスにアクセスすると、Azureファイル共有パスにシームレスにリダイレクトされます。

• 異なる物理サイトにある複数のサーバーに配布される論理データセットの共通名称を確立します。例えばAzure File Syncを通じて。この例では、\\contoso\shares\FileSyncExampleのような名前は\\FileSyncServer1\ExampleShare、\\FileSyncServer2\DifferentShareName、\\FileSyncServer3\ExampleShareなどの複数のUNCパスにマッピングされています。 ユーザーが使いやすいUNCにアクセスすると、可能なUNCパスのリストが表示され、Windows Server Active Directory(AD)サイトの定義に基づいて最も近いものを選択します。

• サイズ、IO、またはその他のスケールのしきい値を超えてデータの論理セットを拡張します。 この拡張機能は、各ユーザーが共有フォルダを持つユーザーディレクトリや、一時データ用の任意のスペースを持つスクラッチ共有に便利です。 DFS 名前空間を使用すると、複数のフォルダーを 1 つのまとまりのある名前空間にまとめられます。 たとえば、 \\contoso\shares\UserShares\user1 は \\storageaccount.file.core.windows.net\user1にマップされ、 \\contoso\shares\UserShares\user2 は \\storageaccount.file.core.windows.net\user2にマップされます。

次のビデオの概要では、Azure Files デプロイで DFS 名前空間を使用する方法の例を確認できます。

すでにDFS名前空間を持っている場合、Azure FilesやFile Syncで使うのに特別な手順は必要ありません。オンプレミスからAzureファイル共有にアクセスする場合は、通常のネットワーク上の考慮事項が適用されます。 詳細については、「Azure Files のネットワークに関する考慮事項」を参照してください。

この記事では、Azure Files特有のDFSネームスペース展開の部分について説明します。 基礎となるWindows Serverの概念および名前空間手順の全セットについては、DFS名前空間の概要およびDFS名前空間の展開を参照してください。

前提条件

DFS名前空間をAzure FilesやFile Syncで使用するには、以下のリソースが必要です:

• Active Directory ドメイン。 このドメインはオンプレミス、Azure仮想マシン(VM)、または別のクラウドなど、どこでもホスト可能です。

• DFSネームスペースサーバーの役割がインストールされたドメイン参加型Windows Serverメンバーサーバー。 DFS 名前空間は、サポートされているすべての Windows Server バージョンで使用できます。

  Important

  Active Directoryドメインコントローラー上でroot統合された名前空間をホストしないでください。 既存のファイルサーバー名を引き継ぐには、専用のメンバーサーバーかWindows Serverのフェイルオーバークラスタが必要です。

• ドメイン結合環境でホストされるSMBファイル共有、例えばドメイン参加ストレージアカウント内のAzureファイル共有や、Azure File Syncを備えたドメイン参加型Windowsファイルサーバー上のファイル共有などです。詳細は「アイデンティティベースの認証」をご覧ください。

• クライアントからSMBファイル共有へのネットワークアクセス可能性。 詳細については、 直接アクセスのネットワークに関する考慮事項を参照してください。

• ドメイン管理者権限、または影響を受けたコンピュータアカウントの servicePrincipalName 属性への書き込み権限の委任。 名前取り継ぎ手続きはActive Directoryオブジェクトを変更し、昇格されたセッションを必要とします。

DFS 名前空間サーバーの役割をインストールする

すでにDFSネームスペースを使っている場合は、このステップを飛ばしてください。

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

さらなるインストールオプションについては、「 DFS名前空間のインストール」をご覧ください。

名前空間の種類を選択する

DFSネームスペースはドメイン ベース と スタンドアロンの2種類のネームスペースを提供しています。 スケール制限、可用性オプション、Active Directoryの要件を含む詳細な比較については、「名前空間タイプを選択する」をご覧ください。

Azure Filesの場合、選択肢は通常一つの質問に集約されます。

• 既存のオンプレミスファイルサーバー名 (例えば \\MyServer\share)を保持する場合は、 スタンドアロンの名前空間 を選び、ルート統合を使いましょう。 この方法はファイル共有をAzure Filesに移行する際に推奨されます。なぜなら、移行後もドキュメントショートカット、埋め込みリンク、UNCパスが正常に機能し続けるからです。 この記事の残りはこのシナリオに焦点を当てます。
• それ以外の場合はドメインベースの名前空間を選びましょう。

スタンドアロンネームスペースには考慮すべきトレードオフがあります:

• ネームスペースのメタデータは、Active Directoryではなくネームスペースサーバーのレジストリに保存されます。 サーバーバックアップ戦略に名前空間の設定を含めましょう。
• 冗長性のために複数の名前空間サーバーを独立した名前空間に追加することはできません。 高可用性のために、名前空間をWindows Serverのフェイルオーバークラスターでホストしてください。
• スタンドアロンの名前空間は、Windows Server 2008モードでドメインベースの名前空間よりも低スケールのターゲットをサポートします。

ユーザーが進む経路は名前空間の種類によって異なります:

ドメインベースの名前空間を選んだ場合は、根統合の段階を省略してください。 名前空間とフォルダターゲット手順は両タイプで同じです。 DomainV2。名前空間の種類として を使用します。

ルート統合で既存のサーバー名を引き継ぐ

ルート統合を用いることで、単一のDFSネームスペースサーバーは複数のファイルサーバー名に応答し、適切な共有にリクエストをルーティングできます。 この機能は特にAzure Filesの導入に役立ちます。なぜなら、以下の点です:

• Azureのファイル共有は既存のオンプレミスサーバー名を再利用できません。
• Azureファイル共有にはストレージアカウントの完全限定ドメイン名(FQDN)を使って対応します。 例えば、ストレージアカウントstorageaccountのシェアshareにアクセスするには\\storageaccount.file.core.windows.net\shareを使います。 この経路は、 \\MyServer\shareのような短い名前を期待するエンドユーザーにとって混乱を招くことがあります。 ストレージアカウント名がドメインプレフィックスの場合はカスタムドメイン名Azure Filesサポートしますが、DFSネームスペースがなければ\\MyServer.contoso.com\shareのような名前は使えません。

ルート統合はスタンドアロンの名前空間でのみ使えます。 すでにファイル共有用のドメインベース名前空間を持っているなら、ルート統合名前空間は必要ありません。

ルート統合された名前空間を高可用性にするには、フェイルオーバークラスター上でホストしてください。 基盤となるクラスタを構築するには、 フェイルオーバークラスタを作成する方法を参照してください。 この方法を取る場合は、個別ノードではなくクラスタ名オブジェクト(CNO)に対してエイリアスを登録してください。

以下の図は、高可用性のルート統合展開を示しています。 Azure Load Balancer は、ルート統合名前空間をホストする DFS Namespaces サーバーで構成された Windows Server フェールオーバー クラスターの手前に配置されるため、それらの共有が Azure Files に移行した後も、クライアントは廃止されたファイル サーバー名に引き続きアクセスできます。

既存のサーバー名を引き継ぐことは、付け加え付けではなく、切り替えです。 以下の段階を順に完了します:

1. DFS名前空間サーバーでルート統合を有効にしてください。
2. 名前空間を作成し、#<old-server-name>という名前空間を使ってAzureファイル共有を追加します。
3. ソースファイルサーバーからサーバー名とサービスプリンシパル名を転送します。
4. 既存のファイルサーバー名に対してDNSエントリを作成します。
5. 名前の引き継ぎを確認しましょう。

根の統合を有効にする

名前空間サーバー上の昇格されたPowerShellセッションから、以下のレジストリ値を設定し、その後DFS名前空間サービスを再起動します。 サービスはこれらの値を起動時にのみ読み取ります。再起動するまでは、名前が #で始まる名前空間を作成することはできません。

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Type DWord `
    -Value 1

Restart-Service -Name "Dfs"

フェイルオーバークラスタでは、すべてのノードでレジストリ値を設定し、クラスタ化された名前空間の役割を失敗させて各ノードがサービスを再起動させます。

名前空間を作成し、Azureファイル共有を追加します

DFSネームスペースの基本的な管理単位は ネームスペースであり、その根は木の出発点です。 \\contoso.com\Public\では、名前空間の根はPublicです。 名前空間内で、フォルダターゲットを持つ フォルダは コンテンツを持つSMBファイル共有を指し、ターゲットを持たないフォルダは構造と階層を加えます。

一般的なWindows Server手順については、「DFS名前空間の作成」「DFS名前空間内のフォルダを作成する」「フォルダターゲットの追加」を参照してください。 Azureファイル共有をターゲットにする際は、以下の点を念頭に置いてください。

• フォルダのターゲットにはストレージアカウントFQDNを使ってください。 フォルダーのターゲットを \\<storage-account>.file.core.windows.net\<share>に向けてください。 Azure Filesはストレージアカウント名がドメインプレフィックスの場合もカスタムドメイン名をサポートしていますが、フォルダターゲットに使うと、紹介ごとに2つ目のDNSとKerberos依存関係が発生します。 カスタムドメイン名に頼っていない限り、FQDNを使いましょう。
• DFS管理で接続警告が出ることを覚悟してください。 Azureファイル共有のフォルダターゲットを追加すると、コンソールがstorageaccount.file.core.windows.netに連絡できないと報告することがあります。 この警告は想定されています。 はいを選択して続行します。
• ルート統合名前空間には # プレフィックスが必要です。 名前空間の名前は置き換えるサーバーと一致し、前置き #が必要です。 MyServerという名前のサーバーを乗っ取るには、#MyServerという名前空間を作成します。 PowerShell の例では、プレフィックスが自動的に追加されます。 DFS管理コンソールには対応していないので、自分で入力してください。
• フォルダ名は古い共有名と一致しなければなりません。 \\MyServer\Financeを開くクライアントは、#MyServer名前空間内のフォルダFinanceからサービスを受けるため、フォルダ名はソースサーバーの共有名と正確に一致しなければなりません。

# Variables
$namespace = "MyServer"                   # Namespace root name. For root consolidation, use the
                                          # name of the file server you're replacing.
$type = "Standalone"                      # "Standalone" for a stand-alone namespace, or "DomainV2"
                                          # for a domain-based namespace (Windows Server 2008 mode).
$takeOverName = $true                     # Set to $false if you aren't using root consolidation.
$shareName = "Finance"                    # Folder name within the namespace. For root consolidation,
                                          # match the share name on the source file server exactly.
$targetUNC = "\\storageaccount.file.core.windows.net\finance"

# Root consolidation namespaces must be prefixed with "#".
if ($takeOverName -and $type -eq "Standalone" -and $namespace -notlike "#*") {
    $namespace = "#$namespace"
}

$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -like "Domain*") {
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
        Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create the SMB share that backs the namespace root. Read-only access matches the DFS Management
# default, because this share serves referrals rather than data.
$smbSharePath = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbSharePath)) {
    New-Item -Path $smbSharePath -ItemType Directory | Out-Null
}
New-SmbShare -Name $namespace -Path $smbSharePath -ReadAccess "Everyone"

# Create the namespace root.
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath "\\$dfsnServer\$namespace" -Type $type

# Create the folder and point it at the Azure file share.
New-DfsnFolder -Path "$namespacePath\$shareName" -TargetPath $targetUNC

# Verify the namespace root and folder target.
Get-DfsnRoot -Path $namespacePath
Get-DfsnFolderTarget -Path "$namespacePath\$shareName"

先に進む前に、名前空間が名前空間サーバー自身の名前で解決されているか確認してください。 古いサーバー名はまだ使えません。次の2段階を過ぎると動作し始めます。

Test-Path -Path "\\CloudDFSN\#MyServer\Finance"

パスが解決しない場合は、クライアントが\\<storage-account>.file.core.windows.net\<share>で直接ファイル共有にアクセスできるかAzure確認してください。 DFSネームスペースはリファーのみを返すため、基盤となる共有に関するネットワークや認証の問題はここで発生します。 詳細については、 直接アクセスのネットワークに関する考慮事項を参照してください。

サーバー名とサービスプリンシパル名を転送します

ルート統合により、DFSの名前空間サーバーは古いファイルサーバーの名前に応答できますが、クライアントがその名前に認証する前に、他に2つの条件が必要です。

• ネームスペースサーバー上のSMBサーバーは、自身のコンピュータ名以外の名前への接続を受け入れなければなりません。
• Kerberosは cifs/MyServer をそのリクエストに対応するアカウントに解決しなければなりません。 もしそのサービスプリンシパル名(SPN)が廃止されたファイルサーバーのコンピュータアカウントにまだ登録されている場合、クライアントは誤ったアカウントのチケットを受け取ります。 その後、「ターゲットアカウント名が間違っています」と表示されて接続が失敗するか、静かにNTLMに戻ってしまいます。

netdom computernameコマンドは両方の要件を処理します。 旧名を名前空間サーバーの代替コンピュータ名として登録し、サーバーの msDS-AdditionalDnsHostName 属性に名前を追加し、対応する HOST/<alias> SPNを登録します。 HOST SPNは暗黙のうちにサービスクラスの集合をカバーし、cifsを含むため、クライアントのcifs/MyServerリクエストはネームスペースサーバーのアカウントに解決されます。 サービスクラスの全リストについては setspnを参照してください。

手作りの setspn 登録証を netdomの代わりにしないでください。 名前空間サーバーのアカウントで cifs/MyServer 登録するとKerberosは設定されますが、SMBサーバーは設定されず、ディレクトリサービスはターゲットアカウント自身の名前から派生しないSPNを拒否します。 詳細については、「DNS CNAME エイリアス経由では SMB ファイル サーバー共有へのアクセスに失敗する」をご覧ください。

1. ソースファイルサーバーをシャットダウンしてください。 ソースサーバーとDFSネームスペースサーバーの両方が同じ名前に対応することはできません。 ドメインからサーバーを削除するのではなく、電源を切ってほしいです。

2. ソースコンピュータのアカウントを無効にしてください。 Active Directory ユーザーとコンピューターで、コンピュータオブジェクトを右クリックし、「アカウントを無効にする」を選択します。 Active Directoryモジュールをインストールしたマシン上でPowerShellから同じことをするには、以下を実行します:

   $oldServer = "MyServer"
   Disable-ADAccount -Identity ($oldServer + '$')
   

3. 元のコンピュータアカウントからSPNを削除してください。 アカウントを無効にしてもSPNは消えません。 古いアカウントに残された登録は次のステップを妨げます。なぜなら、同じ名前を2つのアカウントで登録できないからです。 重複するSPNは KDC_ERR_PRINCIPAL_NOT_UNIQUEの原因として記録されています。 詳細については、Kerberos で KDC_ERR_S_PRINCIPAL_UNKNOWN または KDC_ERR_PRINCIPAL_NOT_UNIQUE エラーが発生するをご覧ください。 登録済みの項目をリストアップし、その後 HOST と cifs のエントリーを削除してください:

   setspn -L MyServer
   setspn -D HOST/MyServer MyServer
   setspn -D HOST/MyServer.contoso.com MyServer
   

   明示的な cifs/ エントリも同様に削除してください。 setspn -L TERMSRVやMSSQLSvcなど他のサービスクラスが表示されている場合、旧名称はSMB以外のサービスを提供しています。 その依存を解決してから続ける。

4. 名前スペースサーバーに旧名を代替コンピュータ名として追加してください。 名前空間サーバーの上位コマンドプロンプトから netdom を実行します。 単一のDFSネームスペースサーバーに対しては、そのサーバーのコンピュータアカウントをターゲットにします。 クラスタ化されたスタンドアロン名前空間の場合は、個々のノードアカウントではなくクラスター名オブジェクト(CNO)をターゲットにしてください。 netdom Remote Server Administration ToolsのAD DSツールに付属しています。コマンドがなければ RSAT-AD-Tools インストールしてください。

   netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
   

   両方の名前を完全限定ドメイン名として指定してください。 netdom ターゲットアカウントの HOST/MyServer および HOST/MyServer.contoso.com SPN を登録し、アカウントの msDS-AdditionalDnsHostName 属性に名前を追加することで、SMBサーバーは旧名への接続を受け入れられます。

   結果を確認します。 /verifyスイッチは、各登録名に対してDNSレコードとSPNが存在するかを確認します:

   netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
   netdom computername CloudDFSN.contoso.com /verify
   

   netdomがすでに名前が使われていると報告しても、その名前は森の他の場所で登録されています。 続ける前に、矛盾するオブジェクトを特定してください:

   setspn -T contoso -F -Q */MyServer
   

   もし返されたオブジェクトが前のステップで編集したソースコンピュータアカウントだけなら、削除はクエリ中のドメインコントローラーにまだ複製されていません。 レプリケーションが収束するのを待つか、PDCエミュレータに対してコマンドを再度実行してください。

既存のファイルサーバー名に対してDNSエントリを作成します

DFS名前空間が既存のファイルサーバー名に応答するためには、古いファイルサーバー名をDFS名前空間サーバーに指す別名(CNAME)レコードを作成します。 具体的な手順は、あなたの組織が使用するDNSサーバーによって異なります。 以下の手順はWindows Serverに付属するDNSサーバーを使用します。

# Variables
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias "$dfsnServer.$domain" `
    -ZoneName $domain

名前の乗っ取りを確認してください

ドメイン参加済みクライアントからテストし、ターゲットAzureファイル共有の権限を持つユーザーとしてサインインしてください。 DFSネームスペースサーバー自体からテストしないでください。ループバック接続はリモートクライアントと同じ認証パスを使わないためです。

1. 代替名前登録がすべてのドメインコントローラーに複製されているか確認してください。 クライアントのキー配布センターが必ずしもあなたが変更したドメインコントローラーとは限らず、Active Directoryのレプリカが常に一貫している保証はありません:

   $oldServer = "MyServer"
   $dfsnServer = "CloudDFSN"
   Get-ADDomainController -Filter * | ForEach-Object {
       $spns = (Get-ADComputer -Identity $dfsnServer -Properties servicePrincipalName `
           -Server $_.HostName).servicePrincipalName
       [pscustomobject]@{
           DomainController = $_.HostName
           HasHostSpn       = [bool]($spns -contains "HOST/$oldServer")
       }
   }
   

   いずれかのドメイン コントローラーが False を報告している場合、レプリケーションは完了していません。 先に進む前にもう一度確認してください。なぜなら、そのドメインコントローラー経由で認証するクライアントでも失敗するからです。

2. 古いサーバー名がDFSネームスペースサーバーに解決されているか確認してください:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. 古い名前で共有を開き、Azureファイル共有の内容が見えるか確認してください:

   Test-Path -Path "\\MyServer\Finance"
   Get-ChildItem -Path "\\MyServer\Finance"
   

4. 旧名に対してチケットが発行されていることを確認し、セッションが NTLM にフォールバックするのではなく Kerberos で認証されたことを確認します:

   klist
   

   サーバーフィールドが cifs/MyServerのチケットを探してください。 Kerberosは、 HOST/MyServer 登録が cifs サービスクラスをカバーしているため、名前空間サーバーのアカウントに対してこのチケットを発行します。 そのようなチケットが存在しない場合、最も一般的な原因は、代替名の登録がクライアントが使用しているドメインコントローラーに複製されなかった、無効化されたアカウントに登録が残っている、またはフォレスト内の他の場所に重複が存在することです。

DNSやKerberosの変更がすぐに効果がない場合は、クライアント側キャッシュをクリアして再試行してください:

ipconfig /flushdns
klist purge

クライアントキャッシュをクリアしても、基礎的な変更がまだ再現されていなければ意味がありません。 もし再試行しても失敗しなければ、他の変更を行う前にステップ1でレプリケーション収束を再度チェックしてください。

アクセスベース列挙(ABE)

アクセスベースの列挙は、ユーザーがアクセス権限を持っていないファイルやフォルダを隠します。 DFS名前空間では、名前空間でABEを有効にするのはその名前空間内の DFS-N フォルダーにのみ適用されます。 フォルダターゲットの内容の列挙を制御するには、ターゲットファイル共有自体でABEを有効にしてください。 ABEはすべての名前空間サーバーがWindows Server 2008以降のバージョンを動作させることを義務付けており、ドメインベースの名前空間はWindows Server 2008モードを使用しなければなりません。 詳細は「 名前空間上のアクセスベースの列挙を有効にする」を参照してください。

Azureファイル共有でABEを有効にできないため、SMB Azureファイル共有内でのファイルやフォルダの可視性をABEで制御するのはサポートされていません。 この制限は、DFS-N フォルダターゲットの前でプロキシとしてではなく、リファラル方式で動作するため存在します。 ユーザーが \\mydfsnserver\shareと入力すると、SMBクライアントは紹介 \\mydfsnserver\share => \\server123\share を受け取り、後者を直接マウントするため、DFS-N サーバーはもはやデータパス上にいなくなります。

ABEはリダイレクトの前にフィルタリングしたい階層のレベルをホストしている DFS-N サーバーでのみ機能します。 以下のレイアウトはどちらも機能します。なぜなら、ユーザーごとのフォルダ名が DFS-N サーバーの名前空間に存在するためです:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1ここで contosouser1 は users 共有のサブフォルダです。

リダイレクト 後に 各ユーザーがサブフォルダになる場合、ABEは機能しません。なぜなら、ユーザーごとのフォルダは DFS-N サーバーによって列挙されないからです:

• \\DFSServer\SomePath\users => \\SA.file.core.windows.net\users

こちらもご覧ください

• ファイル共有アクセスの構成: 直接アクセスに関する ID ベースの認証 と ネットワークに関する考慮事項。
• DFS 名前空間の概要
• DFS 名前空間の展開
• 名前空間の種類を選択する
• ネットダム コンピュータネーム
• setspn
• SMBファイルサーバー共有はDNSのCNAMEエイリアスによるアクセスに失敗します
• フェールオーバー クラスターを作成する