1 Reply Latest reply on Jul 4, 2018 7:46 AM by phoffmann

    Multiple domain and one Core Server

    bhavikdesai17 Rookie

      Hello,

       

      I would like to know how we can have multiple domain on one LANDesk Core Server and also another question is how much devices a SQL Express can support.

       

      DO I need to make any entries for multiple domain.

       

      How can I manage multiple domain (clients) with one core server which is in a different environment and client domain are all in different environment.

       

      Using Ivanti EndPoint Manager 2018

       

      Would be looking forward for the right updates

       

       

       

      Thanks

      BD

        • 1. Re: Multiple domain and one Core Server
          phoffmann SupportEmployee

          So there's a few gotchas with both those questions to be aware of.

           

          Point 1 - "multiple domains" ... the short version is "doesn't REALLY affect us all that much".

           

          Longer version:

          • The "multiple" domain thing is primarily a headache around deploying the agent in the first place. You can do this via GPO's or multiple sets of credentials ... once the agent is down, by and large, we don't REALLY much care about "multiple domains" from a "talkign to clients" point of view.
          • Software distribution CAN get interesting, especially if you have unreliable DNS somewhere / throughout those domains.

            You may find that using HTTP-shares, or specifying IP-addresses rather than relying on DNS helps a lot.

            You may also want to use domain-specific Preferred servers (that way you can handle domain-specific credentials quite easily, for instance), and/or consider "vanilla" but unsecure HTTP-shares, depending on what headaches you have.
          • Active Directory CAN be a headache if you expect people from multiple domains to log on to the Core and those domains don't trust each other. You CAN have multiple active directory sources, but you want to make your life easier / simpler & "use one domain" as the administrative domain if at all possible.

           

          • Another potential headache is you need to resolve from multiple different active directories ... be aware that the Scheduler service can ONLY use multiple credentials for PUSHING out the agent (which you don't want to do) as an RPC, if need be. The PRIMARY account the user runs in is what gets used to calculate hashes for files & software packages ...

            so make sure that's something you control sensibly & if you need to host packages in other domains, use preferred package servers for that.

          ----------------------

           

          Re point 2:

          SQL Express is limited by size - 10 GB at present, if I am not mistaken. The reason why this is a bit of a "gotcha" is that the amount of data per client (on average) can vary QUITE a bit depending on what you do / do NOT use.

           

          A pretty clean Core with a fair bit of Patch content downloaded (for instance) is going to take up roughly 5 GB (give or take, I download a lot of vulnerability content you might not, for instance).

           

          Then, expect each client to be somewhere between 5-10 MB (as much as 20 MB) of data, depending again on "what you use", "how you configure things" / "how long you keep stuff / history / auditing data" and so on.

           

          So there are various "best case" / "worst case" scenarios, which really depend on how much you're looking to use. Be aware that SQL Express is also lacking various other key features that SQL Standard for instance will have (aside from CPU & disk-size limitation, for instance).

           

          But if we're going to assume ~5 MB per client, and set aside 5 GB for vulnerability content, that gives you roughly 1,000 clients to play with. Again - this is very much a "Your Mileage May Vary" category, as you could be doing (for instance) a LOT of provisioning & not clearing out the provisioning history for some regulatory or procedural reason for instance which will skew this.

           

          Hope that helps a bit, but it's not really the sort of thing that can get you "hard firm numbers" of the "500 nodes is OK, 501 is not!" variety, as there's simply too much that depends on what you use & how you use it.

           

          Does that help / make sense?

           

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

           

          So - all of the above "can be done", there's just a few things to look out for (a lot of it being "DNS" really).