9 Replies Latest reply on Dec 20, 2018 2:23 PM by phoffmann

    using DFS namespace as source

    abnranger6789 Rookie

      Hi all, not sure if this a redundant approach, but we are having serious network slowness when deploying our images. I was wondering as a possible solution if we can use DFS(R) in tandem with the preferred servers. My thinking is that we create a DFS(R) namespace (combining all the preferred servers in the replication group), then pointing the source to the namespace in the preferred server configuration. One other thing to consider is SMB signing. Anyone addressed this as part of their performance tuning for their Ivanti network? Thanks for any and all responses.

        • 1. Re: using DFS namespace as source
          joeh SupportEmployee

          Hi. Is your query regarding the 'AppSense' Management Center?

          • 2. Re: using DFS namespace as source
            abnranger6789 Rookie

            Sorry not speaking about Appsense, I am referring to the preferred server that the endpoint manager uses for distribution. I am wondering if the shares (sources) that the preferred servers and core point to can be setup as a DFS(R) namespace

            • 3. Re: using DFS namespace as source
              joeh SupportEmployee

              Hi. You're in the wrong forum, this is the one for the former AppSense Management Center. I think you'll need one of the EPM forums - try here: Endpoint Manager and Endpoint Security (EPM) (Powered by LANDESK) .

              • 4. Re: using DFS namespace as source
                randyb1 SupportEmployee

                abnranger6789 I have moved this thread to the EPM forum.

                • 5. Re: using DFS namespace as source
                  phoffmann SupportEmployee

                  Can you explain a little more context here? I'm trying to understand quite what the purpose is of "combining" DFS with PPS (Preferred Package Server) for your scenario.

                   

                  So if we have a DFS share "\\MyPackageShare\MyPackageDir\" ... then DFS will (ideally) assign the closest server to a given request.

                   

                  PPS'es operate similarly ... but it's a "simple" server substitution. So say you begin with the following path / file that you're looking to get on a client -- "http://MyCoreServer/MyPackageShare/MyFile.exe" ... how PPS's work is that we check whether there *IS* a PPS configured for a given client, and - if so - substitute the server name. So we effectively automatically rewire to ==> "http://MyLocalPPS/MyPackageShare/MyFile.exe" automatically.

                   

                  (Note that PPS'es work for both HTTP and UNC shares, which is a big plus).

                   

                  I'd argue that "it COULD / should work" ... but I fail somewhat to see the benefit (somewhat similar stunts can be pulled with DNS aliases of "http://GenericServerThatGetsResolvedBasedOnLocation/MyPackageShare/MyFile.exe" (or whatnot), but I've failed to see the benefit there (especially as DNS is more often than not less than trustworthy in the first place).

                   

                  ... so I suppose along with the question of "CAN you", I suppose the other half is "to what end"? If you're using UNC ... that'd help you with DFS, but by and large UNC is pretty crappy for package hosting (HTTP is much more suitable for that), and I personally prefer HTTP (personal bias). If you "need to" use UNC for whatever reason, and UNC only, then DFS makes sense.

                   

                  If you need to use HTTP as well (since PPS'es work with both), using "just PPS" or a combination of both may be of some help.

                   

                  Not sure that ANSWERS your question, but I'm hoping it provides context / gives you some questions to answer for yourself & then make a decision off of.

                  • 6. Re: using DFS namespace as source
                    abnranger6789 Rookie

                    Hi thanks for that response, and yes I totally agree and understand how the PPS works., I guess I was trying to add some umph lol to the process. Now I was advised by an Ivanti tech to not use http for batch packages, only use UNC. That is for another discussion lol. While I have your ear, what about branchcache? Configure the shares with that to help take some load of the bandwidth.

                    • 7. Re: using DFS namespace as source
                      phoffmann SupportEmployee

                      Never used BranchCache / never heard of it 'til now ... so ... sorry - can't help there .

                       

                      I use HTTP for everything in my lab & haven't had issues with BAT files there ... not sure where that comes from. HTTP *can* bite you in the bottom with MIME types (gets interesting when you need to specify "*." because of extension-less files and such) ... but "it works fine" if configured right by and large.

                       

                      Remember also that we *DO* make use of peer download, so it's not like there isn't tech on our side to make distribution easier already .

                       

                      Then there's Subnet-aware downloads etc ... there's a LOT of tech we have to make software distribution easier / more efficient...

                      • 8. Re: using DFS namespace as source
                        abnranger6789 Rookie

                        Thanks for the insight. Yeah branchecache is built in to the OS, but can be better leveraged using GPO across the network. Anyway, I appreciate your knowledge.

                        • 9. Re: using DFS namespace as source
                          phoffmann SupportEmployee

                          Eh - everything is just perspective & limitations.

                           

                          Plenty of other folks around as well who can chie in if needed. Let us know if you run into anything particularly egregious or whatnot that you need a hand with .

                           

                          (Or just to bounce ideas off of).