Quantcast
Channel: Symantec Connect
Viewing all articles
Browse latest Browse all 22530

DFS migration

$
0
0
I do not need a solution (just sharing information)

Hi, I thought I'd share with you an experience of how we got PST migration working across DFS, as I couldn't find anything on it (apart from it not being supported/possible).  

In our environment, users keep PST files on their network drives.  These are DFS shares.  The DFS servers are also Domain Controllers.  But not all DCs are DFS servers. 

When we initiated a client side migration, it would not archive anything from a DFS share.  A trace of the migrator task showed the following:

Source Path [\\contoso\data\australia\sydney\it\Enterprise Vault\test1.pst] Broken Into [CONTOSO] [data] [\australia\sydney\it\Enterprise Vault\test1.pst]

and

Source Path [\\sub.contoso.com\data\australia\sydney\it\Enterprise Vault\test1.pst] Broken Into [SUB.CONTOSO.COM] [data] [\australia\sydney\it\Enterprise Vault\test2.pst]

The server is looking for a computer called CONTOSO which does not exist as it's our domain name. In the log we get:

First Call to ::NetShareGetInfo() Failed [0x00000035]

PstTranslatePath - Computer [CONTOSO] is not a NETAPP device so no futher [sic] attempts will be made to resolve the network path

It had an issue resolving CONTOSO into anything it can understand.  So on the EV server, we created a hosts file entry which resolved CONTOSO to an IP address of a DC which was running DFS, as well as FQDN SUB.CONTOSO.COM (as this would sometimes resolve on a server which was not running DFS).  We could then translate \\contoso\data and \\sub.contoso.com\data into a vaild computer and path.  So with name resolution solved, we then started seeing:

PstTranslatePath - Raw Translated Path [d:\DFSNamespaces\Data]

PstTranslatePath - Translated Path [\\CONTOSO\d$\DFSNamespaces\Data\australia\sydney\it\Enterprise Vault\test1.pst]

We realised that in order to access the administrative share which is what DFS does, we had to grant the service account elevated rights, in our case Domain Admins, as that was the only group which had access to all shares and files (Power Users wasn't an option for us). 

Our only concern is if that server in the hosts file goes down, we need to change it to something else, plus DAs on the service account isn't good.  But for the duration of the migration it will have to do.  So far everything is working as it should.

Cheers.


Viewing all articles
Browse latest Browse all 22530

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>