Hi my name is Will Gries, and I'm
a Program Manager on the Azure Files team. In honor of Ignite,
let's talk about one of the key features that was
released for Azure Files over the last year: the ability for
an Azure file share to be domain joined to your on-premises
Active Directory domain. This enables you to replace an on
premises file server with Azure file shares. This can be done in
just five simple steps and actually only the first step is
really required. Just like an on-premises server, the very first
thing that needs to be done is to domain join your storage
account to your on-premises domain. So let's do that. So
here I have a storage account with a file share that I'd like
to be able to mount from on-premises. To domain join this
storage account, I'll open up PowerShell, and I'll import the
AzFiles hybrid module which gives me the cmdlets that
I'll need to do the job. The cmdlet that I'll use is
the Join-AzStorageAccount cmdlet. Just like a regular
Az PowerShell cmdlet, I'll need to provide the resource
group name and the storage account name on the object I
want to act on, which in this case is this particular storage
account; and the domain name of the domain that I'd like to be
domain joined; the resource type that I want to create, which in
this case is a computer account; and the organizational unit I
want to put this object in. And just like that I have domain
joined this particular storage account. Just like my on-premises
file server, before I can actually access this share from
on premises, I'll need to put a share ACL on either the storage
account or on the individual file share. And when I do so on
the storage account that share ACL will apply to all of the
shares underneath. In this particular case, I'll put it on
the storage account level. I only have one share in there anyway. And I do this by adding
a role assignment, so I'll add the role in this case I can
search for SMB share elevated contributor and I'll type my
name - I could add a group here as well, but I'll type my
individual user account and add that as a role assignment. Now that the role assignments
have successfully been applied, I can actually mount this file
share on-premises. Before we do that though, I want to refer
you to these links to our documentation, which will show
you how to do everything that I just did in your own environment.
Before mounting the file share, a best practice is to test the
network connection to Azure Files. I can do that by opening
up the PowerShell prompt and using the Test-NetConnection cmdlet to do this test. The computer name parameter is
the fully qualified domain name of the storage account, so
storageaccount file.core.windows.net, and the
common TCP port will be SMB. As you can see, this failed for
me. Like many of you, I am on a network that has port 445, the
SMB port, blocked. If this succeeded for you, you can be
done. You do not have to continue for further, but if
this failed we have an answer and the answer is to create a
private endpoint for your storage account. So private
endpoint gives your storage account a private IP address
within the IP address space of a virtual network. This enables
you to tunnel from your on premises network
into your Azure network, working around the port 445 issue. So to
create a private endpoint, I navigate to the private endpoint
connections tab on the left hand side of the screen; I click new
private endpoint; and then I provide the information for the
private endpoint resource like the name and the region. So there's actually no
requirement that this be the same region as the storage
account, but in this case I actually desire that, so I'll
create it in France Central, where my storage account was
created. I hit the next button and I need to input the
resource type, which in this case is the storage account,
and the actual name of the storage account, and then the
service that I want to connect to. The configuration tab shows me
the virtual network that I need to attach to, and it actually shows me another
important item, the private DNS integration settings that you
see underneath that, but for now let's put a pin in that and go
create the private endpoint. Click create, and just like that,
you end up with a completed private endpoint - I did speed
that up a little bit, but it's actually a pretty quick
deployment. These doc links will show you more about how to
create private endpoints. Now that I've created my private
endpoint, I'll need to set up that VPN tunnel between my on-
premises network or workstation and my Azure virtual network.
This is a rather involved process, and I actually don't
need to do this for every file share, I can do this just once, but I'm not going to show how to
do this in this video - instead, I'll direct you to these links
to learn more about how to set up either a site to site or a
point to site virtual private network, but I just wanted to
show I actually have done this in this case. So to demonstrate
this, I'll go into my private endpoint resource and I'll
actually look at that IP address for my storage account. So let
me just note that down. So I'll do the
Test-NetConnection again. And I'll instead supply the IP
address instead of the computer name and again SMB, and you'll see that this time it
actually succeeded. So that's exactly what I expected to
happen, and so my I know my connection is up and running. So
you might have noticed that I used the private IP address of
the private endpoint rather than using the fully qualified domain
name of the storage account. The reason that I did this is
because the name of the storage account will resolve via the
DNS look up to the public IP address for the storage account, rather than the private endpoint
that we just created. You can see this by using the
Resolve-DnsName cmdlet in PowerShell to resolve the DNS
name to a particular IP address. This is equivalent to nslookup
on Windows or on Linux if you'd prefer to use that. And as you can see, when I did
this resolution, I get back the public IP address of the storage
cluster that hosts my storage account in Azure. I want to
actually change this to point it at the private endpoint. So to
do that I have actually deployed a VM in Azure that will act as
an intermediary between my on- premises domain controller and
DNS server and my cloud private DNS zone that was created when I
created the private endpoint. So I called it CloudDNS and
as you can see, here's a remote desktop connection to
my cloud DNS server. You can see that I've actually
installed the DNS server role; I didn't install anything
else, this is the only thing I did before recording this
video. And then over on the left hand side of the screen
here, I have my on-premises domain controller and my cloud
domain controller. So I'll create a conditional forwarder
on my on premises domain controller for
core.windows.net and I'll point at my cloud DNS
server that I'm actually remoted into. As you can see, the validation
of this IP address failed: don't worry about that, that's
expected. Now if I go to my cloud DNS and create a
conditional forwarder there, I can forward the same name
core.windows.net to the special IP address inside of my Azure
vnet which actually covers the default Azure DNS service and
therefore the private DNS zone that I created. So I'll quick do
a refresh of the cache to make sure that I respond back with the answer that I expect. I'll
do a refresh of the client cache over here on my
client, and now if I do the resolution of the name I will
actually get back the appropriate IP address rather
than the public IP address. So you see that this resolves to
the expected private endpoint IP address that I wanted.
Before we move on, I'd like to show you the following
resources where you can learn how to do what I just did. A common question that we get is why you have to use the fully
qualified domain name of a storage account rather than some
other name like, for example, the name of the storage account or
an arbitrary name like an existing file server name. The
reason for that is because we use the fully qualified domain
name to actually find which storage account you want to talk
to. You can see this through the following cmdlet. So we
provide a Get-AzStorageAccountADObject which will get the object in your Active Directory domain,
which represents your storage account. This object contains a
property on it called the service principal name, which is
used as part of Kerberos authentication, to say which
server, which resource you're trying to access. If I look at the klist or
Kerberos list command, I can actually see that I've got a
Kerberos ticket issued for this particular share. So when I
access the share via File Explorer, Windows under the
covers will get a Kerberos ticket for that name and pass it
on via the SMB session to mount the file share. So now that
you've seen why you mount the file share with that particular
name, the next question that we often get is: is it possible
to use an alternate name like for example an existing file
server name to mount the file share and the answer is yes, you
can actually achieve that with the DFS-N. So, a reminder, this step
is absolutely optional - if you want to just start using your
file share, you can with the storage account fully qualified
domain name. So this is really about taking over an existing on
premises file server name. So here I have my file share again.
I've created a file on it since we last looked at this and now
I'm going to show you how to set up DFS-N. So I'll go back to the
main resource group, and you'll see that I've actually pre deployed
a VM to be my DFS-N server. And I actually have that open, so I can
remote into this, and you'll see that I've already installed the
DFS namespace or DFS-N server role to be able to act as
an intermediary and take over my existing file server name. To
make use of the DFS-N server role to take over an existing
file server name, I'm going to use a feature of DFS-N called
root consolidation. This features is a little hidden - it's
actually enabled via the registry: I have a PowerShell
script that will actually set the registry keys that I need,
so let me run this. And now that these registry keys are
set, I can go and create an A record for this particular
server name, which happens to be called MyServer. And I'll assign it the IP
address of this machine, and add host. Awesome. Done. And now I can
configure DFS-N to take over this name, so I'll add a new namespace. So I'll type in this
server's name and click next. I will type in the old server. I
want to take over the name for prepended with a pound sign or a
hashtag symbol, depending on which generation you're from. I'll click next. I need to select a
standalone namespace - the root consolidation feature only works
with the standalone namespace option. Click next, and
finally click create. Now that I have my created
namespace, I can navigate into it and create the folder target
for my share. So I'll call this just simply share and add the path to
my storage account, which can be seen with the fully qualified
domain name of the storage account and the share. Now that I've done that, I can
pull open my client side File Explorer and type in the name of
my old file server: MyServer, and the name of my share that I
want to access. And now you'll see that just like before I have
connected to my Azure file share with my old name and I can see
the file that I have in that file share. To learn more about
how to use DFS-N please visit the following link. Using these
five steps, I have replaced my on premises file server with an
Azure file share. If you have any
questions about this, don't hesitate to reach
out to us at azurefiles@microsoft.com
and we'll get right back to you. Thank you.
