6 Replies Latest reply on Sep 1, 2010 6:41 AM by PaulYates

    Best practice for multi site deployment?


      Hi There,


           I am in the process of moving LDMS from a single site to around 30 sites on a single core server and was wondering if anyone has any advice on the best way forward with software packages?


           We are going to end up with several people needing to be able to distribute packages for their local sites, but I am intending of having one central team of package builders so that we can keep some kind of control. I would like to split packages into those which are common across all sites (Microsoft office for example), and site specific ones, and then allocate these packages to staff as appropriate, but this does not seem possible. Therefore, I think I am looking at a huge list of packages, which everyone who can distribute software can access. Is there a better way please?


           Cheers - Paul

        • 1. Re: Best practice for multi site deployment?

          What version of LANDesk are you using? Are you planning to have multiple cores or just one and several Preferred servers?

          • 2. Re: Best practice for multi site deployment?



                 I will be having just one core with multiple preferred servers.


                 Hopefully, by the time we go fully live, we will be on LDMS V9 SP2.


                 Cheers - Paul

            • 3. Re: Best practice for multi site deployment?

              With a single core, its pretty easy to manage software distribution. Copying the files to the preferred servers is manual, but you could make a simple script to perform the task for you. With preferred servers, the agent will negotiate where to get the distribution package from based on what you define in the preferred server configuration.


              As for everything else, you can create a User Role and specify what scope it will use. For example, create queries for the various sites you will have ( I am guessing the devision will be by subnet), create a scope based on the query and then associate the scope to the role. Then associate a group to the role.

              • 4. Re: Best practice for multi site deployment?

                I understand that you can use scopes to restrict which devices a user can push software to, but I want to restrict which packages a user has access to.


                I may want to stop a user from site A seeing a package which was developed at site B. I am not aware of being able to handle that with scopes. Please correct me if I am wrong.


                My preferred servers will most likely be replicated DFS shares, so copying packages around the estate will be totally automatic.


                Cheers - Paul

                • 5. Re: Best practice for multi site deployment?

                  No, I don't believe there is a means to limit what users can see in Public, but only administrators can see into All for things that are in My. An Administrator can take a copy of what is in Public and paste it into My for users.


                  Alternatively, with LDMS 9, you can export/import or do a core sync to replicate packages and then assign users to specific cores. The downside is you would have multiple cores, but I believe the core doesn't require a license so you can have several.

                  • 6. Re: Best practice for multi site deployment?

                    OK, I'll answer my own question


                    In a word TEAMS! By defining a team as a site, I can limit queries, packages and tasks to just that team (site). Perfect!.