5 Replies Latest reply on Apr 20, 2018 3:20 AM by phoffmann

    App deployment on a new build

    jdseymour01716 Apprentice

      I'm having a number of issues with EPM 2016.3 (SU6) with regard to Software Distribution and would like some guidance from the community.

       

      We have a project coming up to rebuild 300+ workstations in a very short time frame (3 days). We have traditionally used OS Provisioning of Windows 7 with a very basic image Wim, then targeted LDAP against AD OUs for application deployment of the core applications.

       

      There is a bug in 2016.3 causing us issues with targeted LDAP when logged on as a local administrator, so we have to RunAs PolicySync as a domain user to kick it off. Unfortunately the list of applications targeted via LDAP using Policy often does not complete, causing us to try running PolicySync again, but this causes it to run ALL the tasks, forgetting which ones it has done.

       

      All our packages have been UNC; I have tried using http but it seems VERY slow in comparison. Network utilisation on a client during the sdmcache phase of a deployment is in single figures...

       

      The issue is for these workstations that the finished build, windows, core apps and cad apps is 70gb(!),. A disk image would be desirable but I can't fathom how it would work with PC naming and domain join using provisioning.

       

      Sorry, this has rambled on a bit too long, but I'm having real problems with the performance and reliability of the installation of apps on a clean build workstation, and would appreciate any help. Oddly, the targeted LDAP used to work perfectly on our 9.0 core, so much so that we are only just retiring it for build use.

       

      Thanks.

        • 1. Re: App deployment on a new build
          phoffmann SupportEmployee

          The "fat" image is something I touch on here -- [Tech Brief On-Demand Webinar 2016] Provisioning with LANDESK Management Suite -- as it happens. (You don't have to watch the vid, I touch upon it in the PPT slides as well).

           

          Personally, I'm not a big fan of "fat" images. It gives you massive amounts of additional upkeep, and you need to make sure you "anonymise" every application correctly (some may not have an issue, like a browser -- others will have much more of an issue with that).

           

          HTTP *shouldnt'* really be "slow" (let alone - "slower"). In fact, HTTP is usually better, as it happens. You may want to poke the relevant network people (maybe the IIS / Apache server on the relevant server is dying?). HTTP - if anything - tends to reduce problems (since it's much better suited to file transfer, while UNC is ... terrible, really) .

           

          As a heads-up, you may want to check in with support. SU8 for 2016.3 has gone into limited release -- not sure if your key issue is addressed in that, but won't hurt to check?

           

          CONCEPTUALLY, a "fat image" is really no different to a "lean" one (where you install the apps AFTER the provisioning & domain join) ... but you have the headaches to deal with of "is the APP going to cope with a device being SYSPREPPED") ... and not all apps do so quitely / well (may involve additional hackery & such).

           

          It's a quick reply, but at least it's a starter for 10..

          • 2. Re: App deployment on a new build
            jdseymour01716 Apprentice

            Many thanks for you reply, I really appreciate your assistance and thoughts.

             

            I am not a fan of 'fat' images either; normally we build devices from an almost 'gold' Windows 7 WIM file - just with .NET 4.5.2/4.6.2 added (for the LANDesk provisioning interface during the System Configuration phase) and then Sysprep - Generalize - OOBE'd. This requirement is a one-off where we are rebuilding 300+ workstations with clean hard drives over a period of less than a week.

             

            I have had to look at a 'fat' image for several reasons:

            1. I'm not sure how our network would cope with 300+ x 70GB of applications going down it at once

            2. The LDAP policysync process has become unreliable from our core; there is no guarantee it will complete all of the scheduled policies, causing us to run policysync again, which causes the core to start again from the beginning, reinstalling some of the applications

            3. It looks like Software Distribution in a provisioning template requires HTTP? I tried putting all of our core apps in a task sequence, but this is how I discovered HTTP in our environment is slower than UNC.

             

            I am not convinced our Preferred Server (HTTP) setup is correct, as it is complicated by the fact that we run DFS for our file shares. The IIS serving HTTP for software distribution is running on the core using an alias; I'm guessing that this is not optimal?

             

            Thanks

            • 3. Re: App deployment on a new build
              phoffmann SupportEmployee

              Hmm - combining Preferred servers / DNS-aliases with DFS does cause some confusion as to where things are coming from - that's true.

               

              A couple of points however (for clarity):

              • A clients' "CurrentDownloads.log" (in -- C:\Program Files (x86)\LANDesk\LDClient\) lists WHAT you downloaded and from WHERE. That can help you be more certain here (this is an "easy form" log).

               

              • When downloading ANYTHING, clients WILL try to do a peer-download first of "any part" of the package. So if you have to provision 300 devices, they WILL peer off each other (so you won't have 300 guys assailing your file server if you stagger it). There is a limit (I seem to recall around 10) of other devices that a peer will serve at the same time (so as not to hammer the NIC / disk I/O completely).

                So a single peer WON'T serve 299 other devices.

                But having done (say) - 10 and then 50 devices DOES give you a lot of "cached up" peers in the network .

               

              • I'm attaching (slightly older - v9.6 I think) peer download annotated logs, in which I explain what messages mean what (so you can make more sense of the logs). I did that a few years back for some customer -- it may help you shed more light into your current situation. (The example logs are "just for a single package" to keep their size sensible and have white space // clear **** markers for my comments).

               

              • Can't help you with the LDAP policysync problems ... but you can work around that for those 3 devices and either just throw their bare-metal / inventory records (or add them to a group and use that group) for those policies. We don't "require" functioning AD (heck, I've had to work with environments that didn't have domains over the years), so there's other fallback options you can make use of ... not necessarily an intended "fix", but a perfectly acceptable crutch for a short project like this one perhaps?

                Remember - there's usually at least 3 different ways of achieving the exact same thing in EPM .
              • Software Dist in Provisioning shouldn't "require" HTTP (plus, we have HTTP <=> UNC failover always enabled anyway), since you just specify "install package X", and the package definition then includes details on whether it's on UNC or HTTP. I'm assuming you're talking about the "Distribute software" action in the SYSTEM CONFIGURATION stage?

                The UNC <=> HTTP failover means that if we can't reach "\\MyServer\MyShare\MyFile.exe" we will automatically try to see if we can access "http://MyServer/MyShare/MyFile.exe" instead (and vice versa).

               

              Hope that helps a bit?

              • 4. Re: App deployment on a new build
                jdseymour01716 Apprentice

                Thank you for your comprehensive reply again phoffmann

                 

                I logged a call with Ivanti for the PolicySync issues with our core version, and after sending them some log files think I may have an answer:

                 

                <quote>

                It looks like the policy sync started with domain user credentials gets interrupted by the policy sync initiated automatically. Since the latter policy sync does not have LDAP information all the policies and their statuses get removed from the machine (that's why the second time you run Policy Sync manually it starts installing all the applications again).

                </quote>

                 

                I have managed to come up with a good workaround, from a slightly unlikely source: Package Bundles. All the applications which were going on to a clean build were individual scheduled tasks targeted via LDAP. While this is nice in one was in that it gives us control of each app in the build, it is a LOT of policies to target. By wrapping the apps up in a Software Distribution Package Bundle, only one Scheduled Task then needs to be targeted via LDAP, which seems to perform much more reliably from my testing.

                 

                With regard to 'FAT' images, I have made some progress on that score too. I got agreement from the first/second line regarding the process for rebuilding the PCs, so joining the domain and installing the agent can be a manual task performed by engineers. This combined with a Sysprep unattend.xml which causes Windows 7 to only prompt for a Computer Name during OOBE seems to work great. Interestingly, the fattest of our 'fat' images came to ~14GB!

                • 5. Re: App deployment on a new build
                  phoffmann SupportEmployee

                  Cool - glad to hear that you've made progress here .

                   

                  Hope the rest of the project is smooth(-ish) sailing ... one can hope .