9 Replies Latest reply on Oct 16, 2008 6:19 AM by zman

    Can't Use Local System or Current User, Now what?

    Apprentice

      Hi All

       

      I have a software package (archicad) which has cresated its own custom install .exe (GREAT I HEAR YOU ALL SAY), well i thought it was. Until I tried to deploy it and it failed on the Local System Account. I did some testing and the package will not install as the local system account. I can not deploy as the current user as it requires admin privileges aswell.

       

      I read on another forum that if you use run from source and use a admin as the user with rights to the UNC package it should install as that user, well i tried that and it doesnt appear to work. I still get an internal archicad error that I need admin rights.

       

      Any other ideas on how to get around this.  Am running LDMS 8.8 SP2 :)

       

      Thanks in Advance

        • 1. Re: Can't Use Local System or Current User, Now what?
          zman Master

          The trick is to configure preferred server, use an account that is a local admin for the pref server account, and use run from source. Make sure you clear sdmcache.

           

           

           

          Also, you could use an Autoitscript or other scripting agent and use the  RunAs command (internal to Autoitscript)  with credentials passed on the command line so they are not in the package. The downside of this is LANDesk puts the command line options on the distro package in the local log files.  I've done some really weird Autoitscript using obfuscator, encrypted passwords on command lines etc... to work around these issues. Try the run from source first. 

          • 2. Re: Can't Use Local System or Current User, Now what?
            Apprentice

            THanks Zman. I am a bit new to LDMS. Can you expand on Preferred server and where to find it?

            • 3. Re: Can't Use Local System or Current User, Now what?
              zman Master

              So one thing you will find out is not all the Console functions are availble on a remote console.

               

              1. So fire up the console on the Core
              2. Select  Configure
              3. Select Preferred Server
              4. Select Help - Read about Preferred Server
              5. Configure Preferred Server

              Configuring preferred package servers
              You can specify the default server that devices will check for software distribution packages. This can be important in low-speed WAN environments where you don't want devices downloading packages from off-site servers. When you specify preferred servers, you can also specify the credentials managed devices should use to authenticate with each preferred server. You can also specify the IP address ranges that preferred server will be available to.

              When using preferred servers with a distribution job, only the server portion of the UNC or URL file/package path is replaced; the rest of the path must be the same as what was specified in the distribution task. If the file isn't on the preferred server, it will be downloaded from the location specified in the distribution package. The only distribution method that doesn't support preferred servers is Multicast (cache only).

              The core server also uses preferred servers. The core server uses distribution package hashes to verify distribution packages in scheduled tasks. The core server will first try to generate these hashes from a preferred server. Using a local preferred server makes the hashing process much quicker. If the package isn't available on one of the preferred servers, the core server falls back to generating the package hash from the path specified in the distribution package. You generally won't want the core server pulling a large package over the WAN link for hashing, so hashing files on a server that's local to the core will be much faster and use less low-speed bandwidth.

              Managed devices store the preferred server list locally in the preferredserver.dat file. To create this file, a device communicates with the core server and then makes a filtered list of preferred servers (based on IP address range limits, if any). The device then does a bandwidth check to each preferred server and saves the top three servers in the preferredserver.dat file. Note that the bandwidth check doesn't produce guaranteed reliable results. For example, a server that's close by may have a high load at the time the agent checks, so it may get bumped off even if normally it's the best candidate.

              The distribution agent updates the preferredserver.dat file every 24 hours or when the IP address changes. Not every device has to go through this process. Devices share their preferred server lists with peers. This is the process managed devices go through to maintain a current preferred server list:

              If preferredserver.dat is in the local file cache, the distribution agent uses it.
              If preferredserver.dat is on a peer, the agent retrieves the file from that peer.
              If preferredserver.dat isn't available locally or on a peer, the device contacts the core server, creates a filtered preferred server list, and saves that locally as preferredserver.dat.
              If preferredserver.dat is empty or if none of the preferred servers respond, the agent checks for a preferred server list in the local registry.
              If none of these steps results in an available preferred server, the local agent uses the distribution path specified in the distribution job.

              • 4. Re: Can't Use Local System or Current User, Now what?
                Employee

                just to point out the other option, application virtualization is another solution.

                • 5. Re: Can't Use Local System or Current User, Now what?
                  Apprentice

                  Virtualisation is toooooo expensive.

                   

                  Thanks Zman. Great help :)

                  • 6. Re: Can't Use Local System or Current User, Now what?
                    Apprentice

                    So just to followup.

                     

                    One you enable preferred server you dont have to do anything to the client or the package to make the job work?

                    • 7. Re: Can't Use Local System or Current User, Now what?
                      Employee

                      If downloading the files as LocalSystem was your original problem, then yes.

                      • 8. Re: Can't Use Local System or Current User, Now what?
                        ecoidan Specialist

                        I had the same issue with a program that would not install as Local System nor would installing as current user because of lack of rights.  I created a SWD package that would run at next login and used the below line to install it. Kinda fun...

                         

                        startasuser.exe hidedos.exe cmd /c runas /user:<Local Admin Account> "setup.exe -s" | sanur <Local Admin PWD>

                         

                        startasuser.exe - Comes with LANDesk

                        hidedos.exe - you can find it in the forums somewhere. It hides the CMD window

                        runas - part of XP

                        sanur - freeware tool, allows you to pass the password to the runas.exe command

                         

                        Worked like a charm.  Weird things we do sometimes not to walk around to several hundred machines, lazy us...

                        • 9. Re: Can't Use Local System or Current User, Now what?
                          zman Master

                          App virt is one of those items that if you just consider the up front costs, then it look expensive. If you consider the time and money saved with:

                           

                           

                           

                          • Regression testing -  the testing cycle is much quicker
                          • Ability to run legacy apps under newer OS. No need to repackage
                          • No additional infrastructure required like other solutions
                          • No dll hell, ability to run under other solutions - Citrix, Thin clients, etc...
                          • Productivity loss on the user side waiting for the app to install or troubleshoot app issues.

                           

                           

                           

                          The costs savings on the back end more than pay for the product.

                           


                          In regards to placing usernames and passwords in exes, that is risky especially in Package Builder apps. Encrypted command lines offer a better solution.