Hosting distribution point in DFS

[snovak]

I've been looking for a better approach when it comes to distributing files, and it occurred to me that I might be able to host it up in our SAN (Huzza 10GBe!) and I was wondering if anyone had any experience hosting files this way. I know in the past SMB has been sort of unreliable, but on Yosemite it's looking pretty good.

[davidacland]

We quite often use SMB and rarely have any issues. It can be a bit slow but it gets there. I think you will still have to use an SMB share pointing to a server FQDN. Last time I checked Casper couldn't use a DFS path as a DP.

[Josh_Smith]

We are using DFS shares, including DFS paths. It is working well in 9.63. There appear to be some issues in 9.65 that break it.

The DFS replication is very nice.

We had trouble with the DFS paths until we set it like this:

example DFS path:

smb://domain/directory1/directory2/directory3/LastDirectory

example Casper settings:

Server: domain/directory1/directory2/directory3
Share Name: LastDirectory

[snovak]

There were (apparently) historical issues transferring PKGs over SMB (though it may be that they were sitting on NTFS), anyone able to chime in on this?

[snovak]

I've successfully dropped an image using DFS as the DP, but now I have another problem: kerberos.

It appears that when the share is mount, the credentials that are used to mount the share (being AD credentials) creates a kerberos ticket, which can be used by the currently logged in user.

Currently when an AD user logs in their kerb ticket is the primary one, but if someone were to open Ticket Viewer and set the other one as they could potentially browse through the DP (which I would rather they not be able to do).

Anyone have any experience with this? Is there perhaps a way to deny tickets being issued to specific network users for AD?

[johncwelch]

ACLs would be how to deal with that

[Aziz]

@snovak

As @johncwelch said, Windows Server ACL. My Windows admin account has an ACL attached to it, that ACL is for accessing /servername/CasperShare. My "casperadmin" and "casperinstall" service accounts also have the ACL. If anyone else were to log on, they wouldn't be able to look at the DP.

[snovak]

Now I seem to be encountering some sort of issue when trying to mount the DFS share as part of a policy:

Executing Policy Install Latest Adobe Acrobat Pro... Mounting DFS to /Volumes/CasperShare 1...
com.jamfsoftware.jamfhelper: Invalid argument
No matching processes were found Could not mount distribution point "DFS". Retrying using distribution point afp://[SERVER]... Mounting [SERVER] to /Volumes/CasperShare 2... Copying Adobe Acrobat Pro-11.0.11.pkg... Installing Adobe Acrobat Pro-11.0.11.pkg..

Can anyone chime in on this?

[bsuggett]

Reporting Back On Our Implementation Of DFS for use as DPs

Creating a single folder in the DFS namespace called Caspershare worked like a charm, file and folder syncing works beautifully. Connecting to the Caspershare works perfectly... however at present the caveat is

Because we're adjusting the setting in the JSS to mount a folder called Caspershare we get into another problem (currently active at the time of writing this post)

Could not mount distribution point
https://jamfnation.jamfsoftware.com/discussion.html?id=10178
Sum up is connecting to different servers with the same sharename ie Caspershare... results in random errors when connecting to DP's. This causes policies to fail randomly....

To get around this we removed the caspershare folder and added the Casper folders ie Packages, scripts etc independently. The results proved that while Windows machines can function as normal in this arrangement. Mac clients run very very slow. The more folders that are in the root of the DFS namespace the worse it becomes.

Conclusion the caveat
Having a single folder at the root of the namespace called Caspershare and then child folders beneath ie packages, scripts etc... Results in the best performance and works perfectly syncing and load balancing however we run into the issue of discussion ID 10178

Having multiple folders called packages, scripts etc at the root of the namespace causes clients when connecting to the DFS namespace, lets say packages directory it could mount a completely different server when connecting to the scripts directory. This causes massive delays for the Mac's and is undesired. Its load balancing the folders and not the servers in this case. The more files/ packages and scripts you have also attribute to more delays as DFS has to work harder.

We've decided at present to use DFS for DP replication only, and use Caspers Load balancing option in the JSS.

I hope this helps...

Regards
Blake