6 Replies Latest reply on Aug 3, 2011 11:08 AM by cyberdemon

    LANDesk 9 transition - Guidance


      We are getting closer on making the decision to move to LANDesk 9.


      In our desired environment, we will be setting up SQL Server 2008 on Windows Server 2008 R2 within a VM instance.

      Our current machine count is: just over 1000 machines, but way under 1500 devices.


      Can someone give me any guidance on properly configuring the above, on a VM?


      for example:


      Does the SQL instance need to be on a separate VM?

      What should I be concerned about when setting this up in a VM?



      If there is a guide, or recommended step by step instructions, aside from the standard SQL/LDMS9/Windows guides, then I would be grateful. While these other guides are helpful, they don't help at all in proper setup for a VM.


      thanks in advance.

        • 1. Re: LANDesk 9 transition - Guidance

          I am no guru by any means but when transitioning from 8.8 SP3 we went from a physical instance of both the core and sql server to VM's for both.  Running a P2V tool for the core was the first step.  Once we had a working 8.8 install running without issue the next step was to create a VM for the server we are going to transition to for both the SQL side and the core server side.  The day of we shutdown the core brought up the new core with the same hostname and ip address.  I can't remember off the top of my head but there was something we ended up doing with the database.  I would have to look through my emails but we are managing 1500 nodes and have had no issues with this current setup.  The vitrualization helps out alot with taking snapshots in the event patches affect the core.

          1 of 1 people found this helpful
          • 2. Re: LANDesk 9 transition - Guidance

            I'll stick on the same "not a guru" disclaimer that DRV used before I start. I'll also highlight that, like many things, your milage may vary (and with LANDesk involved, it almost certainly will). We did this with support from our LANDesk supplier, however, so I hope they knew what they were doing


            Oh, another caveat is that we took the below approach because we had to keep the 8.8 core around as some sites made extensive use of custom reports which, at the time, would not have migrated to 9.0 - this is less relevant since SP2 as, in most cases, I beleive it's possible to get 8.8 reports up and running in 9.0.


            Around 12 months ago we went from an 8.8 physical core, with SQL on the same box, to a 9.0 VM, using an existing general-purpose SQL VM already in the environment and hosting a few different line-of-business databases.


            I think, with the numbers you're talking about, LANDesk would always recommend running SQL on a separate "box" for performance reasons, however, our main motivations was licensing and management (We already had a SQL server and 1 is cheaper and generally easier than many). Some would argue that the DB access profile of LANDesk is quite different to most LOB applications, and benefits from a dedicated SQL server tuned appropriately. For many thousands of devices, that's certainly true, but for "just over 1000 machines" I'd suggest it's not that critical. Just make sure the SQL VM is sensibly configured. It should be obvious that 512Mb RAM and a single vCPU will not cut it.


            We backed up the DB from the old core, and restored it to its new home on the existing SQL server. Our contractor did some housekeeping directly on the DB at this stage. I can't tell you exactly what, but it was mainly to clean out some of the detritus we'd picked up (or created) over the years prior. We then created a new core VM, ran the standard LD install, pointed it at the restored DB and let it upgrade. I don't recall much more being required (but I'd check with LANDesk directly)


            At the time we treated devices as unmanaged and pushed out new agents. The had several advantages - sites could migrate at their own pace, and those locked into 8.8 reporting had time to re-create reports in 9.0 before moving their devices. It also meant, if everything went monumentally wrong, we still had a perfectly functional core (well, as much as 8.8 was functional) still up and running that we could fall back to.


            The downside is that managing the migration of all those agents was a PITA. It also means we had to give the new core a differnet name, of course. We now have an 02 server when there is no 01 server. Not a biggie unless you're anally retentive like me. We have subsequently transfered the certificates from the 8.8 core to the 9.0 core, set up a CNAME alias from old to new, and decommissioned the old box.


            I'm not sure it's necessary to P2V the original core as DRV did, although I guess it could help you understand how your LD environment is going to behave in a virtualised environment. Either way, if you do take the approach of keeping the same name and cutting over from old to new at a specific time (which we'd probably have done if we didn't need to keep side-by-side cores), you must remember to copy your old certificate to the new server first, else your new core will not be able to manage any of your devices.

            • 3. Re: LANDesk 9 transition - Guidance

              I appreciate both your feedbacks. Tried to give you both "helpful answer", but apparently it only gives to the first person you click on. Guess I learned something new. But, wanted to give you "helpful answer" in written form.


              Here is how I think this will play out, based on KISS (keep it simple stupid). Learned that somewhere here in LANDesk land, but at any rate....

              I think we'll end up putting both the DB and the LD core on the same VM box (exactly how it is now physically). Only, it will be Win 2008/Sql 2008, rather than Win 2k3/Sql 2005 (munged from conversion from SQL express....took the NetworkD LANDesk experts 3 days to convert the database to SQL 2005).


              Stand up new DB and Windows, and LDMS 9.x (along with the mobile devices pack), name the server the same as the old (do all of this within the vic console).

              move the certificate as you've mentioned, as well as other scripts, and querries, and anything that can move over.

              I understand that we lose patch history (small price to pay imho).

              Then when it is presumed "stand up" worthy, enable the NIC, shut off old server and see if the clients (which are fully patched/upgraded currently) start checking in with the new VM server and if not, get dear old dad on the phone (LANDesk support).


              Of course it's more thought out, and written down what our proposed steps are, but in the interest of KISS on here, that sums up the idea.

              Any helpful tips/suggestions are always welcome.


              thanks all.

              • 4. Re: LANDesk 9 transition - Guidance

                If you're not migrating inventory data, it will be necessary to get clients to do a full sync, as they'll be expecting to be able to submit a delta. I think in that scenario, the core will tell the agent to submit a full sync anyway during the next inventory scan, but that may then take 2 inventory cycles to get the database repopulated. Up to you whether that's an issue.


                Other than that, cross your fingers and have a 6-pack of beer on hand to celebrate success or commiserate failure

                • 5. Re: LANDesk 9 transition - Guidance

                  Oh, and you could always give me the 'Correct' answer, hehe

                  • 6. Re: LANDesk 9 transition - Guidance

                    Just because I like the beer suggestion! hehe