12 Replies Latest reply on Mar 21, 2018 9:13 AM by phoffmann

    Can´t change scheduler login

    Rookie

      Hello,

       

      what are the requirments to change login in the scheduler service? When I´m trying to change it in Configure/Services/Scheduler/Change login it won´t apply.

       

      It ends up with an error "Failed to grant logon as a service rights". The credentials are for the client PC,

       

      Thank you

        • 1. Re: Can´t change scheduler login
          Rookie

          On my second attempt I´ve entered login "Administrator", which si a user in Ivanti Console Management, and it ends with an error: Service configuration is unable to start the service.

          • 2. Re: Can´t change scheduler login
            carlos Expert

            this has to be an admin account on the server.

            You must also be logged in as an admin in IVANTI console, if you are on a domain, you can use an Admin domain account set up for use with Ivanti, and dont forget the COMs Identity accounts!

            2 of 2 people found this helpful
            • 3. Re: Can´t change scheduler login
              phoffmann SupportEmployee

              Yep - what carlos said.

               

              If you want to edit the PRIMARY credentials (important, as THAT is the set of credentials Scheduler uses to connect to UNC shares to calculate hashes for software, for instance), then you can do so via the regular "Windows Service" properties as well.

               

              If you want to add ADDITIONAL credentials for another reason (mainly for pushing clients -- which should be the last way of deploying to use, really), then you need to do that inside the CONFIGURE SERVICES option inside the Core's Console (and be an admin on both the OS side as well as the EPM side).

               

              We don't generally wany "any Tom, Dick or Harry" to be able to fool around with service stuff & break things, for understandable reasons .

              1 of 1 people found this helpful
              • 4. Re: Can´t change scheduler login
                Rookie

                Thank you for your answers. Well, now I´m not completly sure if I´m attemping the right stuff

                 

                Basicly I thought, that that in the window a I´ve described above, is the login that is attemping to log on the client PC and deploy/install the agent on it.

                 

                So, am I right or completly wrong?

                 

                Thank you

                • 5. Re: Can´t change scheduler login
                  phoffmann SupportEmployee

                  OK - perhaps a few screenshots to help along.

                   

                  1 - You can configure the PRIMARY account of the scheduler in the normal Windows Services window, like so:


                  <Notice that in the top it says "LANDesk Scheduler Service" >

                   

                   

                  2 - You can ALSO configure it via CONFIGURE SERVICES here:

                   

                  These two are "the same thing".

                   

                  Now - for ADDITIONAL credentials (again, only needed if you PUSH agents out), you can use the "Alternate credentials" button in the "CHANGE LOGIN" window

                   

                  These would get used (in times past usually) if you need multiple credentials to work through to push an agent out. I.e. "Try the primary credentials. If that doesn't work, try "SomeDomain\IamSomeone" to push the agent in this example.

                   

                  =============

                   

                  Couple of notes though:

                  • The PRIMARY account (the identity the service runs as) is the most important one, That's the account that gets used to access package shares & calculate file-hashes with. So that's a VERY important consideration (use "the wrong" credentials here, and we won't be able to access/calculate package hashes and you won't be able to do software distribution in essence )!

                  • You generally shouldn't use the "Push agent" method to deploy agents other than as a last resort. It's little more than a RPC call (Remote Procedure Call) that copies files (1 by 1) and tries to install the agent. Lots can go wrong & you wouldn't get any feedback.

                    MUCH, much better to use Advanced agent for instance, which makes use of peer-download, byte-level checkpoint restart & generally "all our soft dist tech", while the "basic push" doesn't use any of that (making it quite inefficient over the network too).
                  • If you're doing this as part of "getting to know" things, that's fine - but you don't want to deploy 5,000 clients out via the push method. We've got much better, faster & more reliable means for that .

                   

                  OK - so far, does that help provide context / enlighten you as to "what is what"?

                  2 of 2 people found this helpful
                  • 6. Re: Can´t change scheduler login
                    Rookie

                    Thank you very much phoffmann for your time, but I still have one stupid questin The first part of the login is the domain? I mean the name before the backslash.

                    • 7. Re: Can´t change scheduler login
                      phoffmann SupportEmployee

                      Correct.

                       

                      "Fantasia" is the name of my (well - one of) lab domain(s).

                       

                      You *CAN* use things like ".\" if you're in a workgroup environment and have a common set of admin credentials.

                       

                      But yeah - that's the domain you're looking at.

                      1 of 1 people found this helpful
                      • 8. Re: Can´t change scheduler login
                        carlos Expert

                        yes, or the server name if it is a local account.

                        yourdomain\username

                        servername\username

                        1 of 1 people found this helpful
                        • 9. Re: Can´t change scheduler login
                          Rookie

                          Yeah, thank you very much phoffmann for clearing thins up. Really appreciate your time.

                           

                          Maybe I would like to continue on your last point, that Ivanti a better method for deploying clients on more workstations. So could you tell what is your recommendation?

                           

                          To get a better view what I am thinking of, we would like to deploys agent on diverse workstations with diverse HW, Windows versions and not domain controlled without a workgroup.

                           

                          And every workstation has only one account, which si a admin account to make things worse

                           

                          Thank you very much,

                          • 10. Re: Can´t change scheduler login
                            phoffmann SupportEmployee

                            So a couple of points:

                            • Diverse workstations -- that's fine.

                            • Diverse hardware -- should be fine (may be some driver conflict is potentially possible somewhere). Would strongly encourage trying to aim for a more homogenous environment to make your life easier, but by and large this shouldn't be a problem.
                            • Different OS'es -- there's a lot that can hide under that. Depending on how far back this goes (i.e. - say you still use Windows XP), you need to be aware of what you're managing as this can decide what version of EPM you should use.

                              For instance, if you DO still have Windows XP and/or Windows 2003 in your environment (and I rather hope you don't), then probably EPM 2016.0 + SU5 is the latest version you want to use, as those still have an "active support" for those OS'es. Anything after EPM 2016.3 will only support XP/2003 with a legacy agent (meaning, no changes can really be applied to it).

                              If we're talking different major OS *PLATFORMS* (i.e.: Windows <=> MAC <=> Linux/Unix) then your approach will have to be different for each OS platform, as they each require their own agent and come with their own specific headaches.

                              ==================
                            • Now, as an introduction into "how to deploy" first of all, make sure you're aware of these articles:
                              - Agent Deployment (note the links to truobleshooting articles for instance if you get stuck)
                              - How to Create and Deploy an Advance Agent
                              - Documentation for Agent Configuration and Deployment for LANDESK 9 release (yes, this is older, but it's still valid)

                              ... now. First of all, a clarifying point. You said...

                              (...) we would like to deploys agent on diverse workstations with diverse HW, Windows versions and not domain controlled without a workgroup.


                              ... which doesn't make sense. A device is EITHER a part of a domain, or it's part of a workgroup. Devices can't be both.
                            • I'll try to include a couple of basic guidelines:
                              • The basic thing to aim for is using Advanced Agent. That allows you to use our software dist tech (i.e. - peer download, byte-level checkpoint restart, etc) to actually GET the "big" agent file on to the workstations in the first place.
                              • This is especially easy if you have a domain, as (if you read the BKM), our suggestion is that you use a GPO to point to the "mini" (2-2.5 MB) MSI file that then downloads the "big" agent file which then automatically gets installed with LOCAL SYSTEM privileges (because GPO) ... job's a a good one.
                              • If you're dealing with workgroup environments, I hope for your sake that you have a consistent set of credentials (and/or that they're smaller in number). In that case, you MAY find that you do need to resort to a PUSH based approach.

                                Bear in mind that this is effectively "just" an RPC call (Remote Procedure Call) where we try to authenticate with the main / alternative scheduler credentials and -- if successful -- try to copy the files down, one by one, and try to install the agent.

                                If things go wrong, you won't have much information to go on other than "well, it doesn't appear in inventory". And with the continued security work on OS'es of hardening the OS'es, chances of something "going wrong" for that sort of thing is not small. (Plus, I find that workgroup "environments" usually have iffy networks as is, and things like DNS being unreliable never help).
                              • Another "last resort" approach idea is effectively giving users (in some cases - e-mailing) them either the "mini agent" MSI, or the "full agent" (with or without UI enabled -- up to you), and asking / telling them how to install it. This is a "potentially doable thing", but I generally find that relying on users to do anything is a recipe for disaster.

                                I highlight it as "a possibility" (that I had to resort to a few times), but if this is your last option, there's a *LOT* of IT policy clean-up / best practice that needs to be caught up with. (Not saying that this is down to you -- if this is the approach you have to take, and there's no "common" admin-account on workgroup devices, chances are there's a whole bunch of similar nonsense out there to complicate your life as well).
                              • ... a reminder - if you cannot trust DNS (and I'd be VERY loathe to), do remember that you *CAN* just talk to the Core via IP in the agent config setting rather than relying on the FQDN or NETBIOS name being resolved. Don't trust DNS to work if you are even slightly hesitant about it.
                              • ... there are other, non Ivanti/LANDesk ways as well. If there already is "some form" of management agent on those devices, use that. It should run as LOCAL SYSTEM which is what we care about. I've helped deploy both SCCM via LANDesk and Ivanti/LANDesk agents via SCCM over the years ... so it's not like "it can't be done". It's a little lateral thinking, but surprisingly simple.

                            ... right - that should hopefully arm you with sufficient info to make some good planning / decisions for your estate(s), I hope?

                            2 of 2 people found this helpful
                            • 11. Re: Can´t change scheduler login
                              Rookie

                              Thank you guys for the help, it was really helpfull. I´ve had now completed the deployment of agents and it looks fine.

                              • 12. Re: Can´t change scheduler login
                                phoffmann SupportEmployee

                                Glad we could help.

                                 

                                If you get stuck with something, the community has tonnes of resources.

                                 

                                There's a lot of free training via momentum here -- Momentum On-Demand Webinars -- that you can access. Helps you to have bite-size, 30-45 minute deep-dives into a particular segment, for instance.

                                 

                                Yes, there's LOTS to learn (true of any management tool really), but the important thing is not to let it intimidate you.

                                 

                                There's usually (at least) 3 different ways of achieving the exact same thing (as I've been claiming for 15 years now) with EPM, and most of that is down to "personal preference / company politics" and similar reasons. So keep an open mind & don't get lost in detail .

                                 

                                If you need help, we're here.