DFS-Namespace through UAG for Content

This post was originally published on this site



As a first post in the communities, I’d like to submit a case that I’ve been unable to achieve with good enough results to release to customers.


We’re trying to implement access to our file systems on DFS-NameSpaces through Content Gateway service on the UAG.

We want to map both Personal and Admin repositories to our users using DFS-N technology.


Content setup :

Repo Type : Network Share

Link : fqdn.domain.comDFS-NFolder{CustomAttribute1}{EnrollmentUser}

Content Gateway : UAG CG


All the DCs have the same DFS-N page set up for all locations as well as the information of all other DCs. We have opened the roads from our UAGs to both all DCs and all the file servers actually hosting the files. The FW opening were done on ports 139 (for legacy) and 445 (for SMB protocol). We have 0 package dropped on any port from our UAGs to destinations targets during the whole process.

When accessing a DFS-N Page, user will be redirected depending on the physical location he’s tagged. We’re using the {CustomAttribute1} to fetch from AD the location of users. This dynamic field in our setup is what enables the DCs to understand where the connection “comes from” and emulate the location of the user so the request is properly resolved to redirect the user to the file server which is hosting their files.

We know the DFS-N works because we can see we’re properly redirected to the actual file server, where the operations launched from Content on iOS client will complete most of the times. The issue is the latency of treatment of the requests. For instance, when downloading a file, the time between DOWNLOAD_INIT_REQ and DOWNLOAD_INIT_RESP is what is plumbing the performances of this. Once the DOWNLOAD_INIT_REQ has been treated, then the file, whether it’s a 10 ko file or a 200 mo file will download at full speed.

This is because the connection will reach out to several DCs before receiving the information.


From the wireshark traces, we could demonstrate that the connection to the different DCs is sequential and goes bouncing from DC to DC until a certain condition (see below) is fulfilled. In that case, the DC matching the conditions will properly return the path to files.

The conditions I’m talking about is about the “path” “alt path” and “node” values found in the FSCTL_DFS_GET_REFFERALS response of the wireshark traces.

A DC will successfully return file server connection information if path / alt path / node have the same value, matching the hostname of the interrogated DC. In that case, we will see indeed the redirection happening to the actual file server and the request being processed.

The behavior when hoping from DC to DC shows that the conditions path / alt path always match DC’s hostname but the node points out to the next hop. We can then see the UAG calling out to this node value.


Mapping the folder as a UNC path works perfectly fine, we access at once the end file server hosting actual data. Then again, in this case, the DFS-N redirection does not happen as we point out directly to the actual file server.

Authentication is not the issue here, we tried mapping an admin folder using my account’s credential and the latency/behavior is still present.


In all traced tests we did, we could not find any pattern that could explain the behavior. Sometimes there are a couple of hops before finding a DC that would match the conditions and return the proper file server to interrogate. Other times we have DC bouncing that goes around a globe and even some DCs which are interrogated 2 / 3 times and still forwarding the connection.


If any of you successfully implemented DFS-N protocol or encountered same kind of issues, I’ll be glad to hear from you.





Default FlashArray Connection With PowerShell

This post was originally published on this site

In the VMware Pure PowerShell module (PureStorage.FlashArray.VMware) there is a default array connection stored in a global variable called $Global:DefaultFlashArray and all connected FlashArrays in $Global:AllFlashArrays. The VMware/Pure PowerShell module automatically uses what is in the “default” variable. The underlying “core” Pure Storage PowerShell module (PureStoragePowerShellSDK) does not yet take advantage of global connections. So … Continue reading “Default FlashArray Connection With PowerShell”

vExpert Cloud Management January 2020 Blog Digest

This post was originally published on this site

Welcome to the first vExpert Cloud Management Blog Digest for 2020! Every month we share a handful of blogs created by our vExpert Cloud Management Community. These blogs are written by industry professionals from around the vCommunity and often feature walkthroughs, feature highlights, and news for vRealize Operations, vRealize Network Insight, and vRealize Log Insight.

The post vExpert Cloud Management January 2020 Blog Digest appeared first on VMware Cloud Management.

Generating an NSX Firewall Rule Report

This post was originally published on this site

One of my customers wanted an easy way to generate a report of all of their NSX Firewall rules as a CSV.  So, simply use get-nsxfirewallrule | export-csv and call it a day, right?  Unfortunately, the NSX Firewall Rule objects are a bit too complex to directly export as a CSV, so I put together a short script to unpack them.  Nothing’s too complex here, but sometimes it’s nice to have an easy script that just gives you the information that you need!

Getting started with VCF Part 13 – Connect vRealize to WLDs

This post was originally published on this site

I’m still on my VMware Cloud Foundation v3.9 journey. My latest task was to connect my vRealize Components to my Workload Domains (WLDs). In part 2 I deployed vRealize Log Insight (vRLI) and vRealize Operations (vROps), and then in part 3 and part 4, I rolled out vRealize Automation. Now I wanted to connect them to the WLDs that I had rolled out previously. SDDC Manager makes this really easy. In just a couple of clicks I had connected vRLI and vROps to both VI WLDs. However, on trying to connect my vRealize Automation (vRA) 7.6 to my WLDs, I…

The post Getting started with VCF Part 13 – Connect vRealize to WLDs appeared first on CormacHogan.com.

NSX-T Two-Tier Routing

This post was originally published on this site

In my previous blog article I covered single-tier routing in NSX-T whereby a single T0 was deployed and provided network connectivity for my virtual workloads. This T0 router provided both N-S and E-W traffic flows. In this article I am going to cover Two-Tier (multi-tier) routing. This topology creates a logical separation between provider and … Continue reading NSX-T Two-Tier Routing