1 Reply Latest reply on Nov 19, 2009 2:05 AM by phoffmann

    Landesk re-installation



      I just would like to know if there is any procedure or technical documentation on How to reinstall LANDESK ?

      I am meeting here a crash of the OS and am not able to restore it so I decided to reinstall the OS and re-install Landesk.

      My database is on another computer.


      Could you help me?


      Thanks a lot for your help.



        • 1. Re: Landesk re-installation
          phoffmann SupportEmployee

          That the DB is on another computer, is a good thing.


          Let me see ... I'm pretty sure I should have this saved somewhere ...




          Ah yes, here - that should help you along (it's rather important that you copy off various files from the current Core - the certs are the single most critical files for that...







          As a general note, in terms of Core-server sizing, please have a look at this following document, as this gives you our recommendations for Core Servers based on the # of nodes they manage (while this document is primarily SQL-centric, the Core-server section would apply regardless):



          That said, here's your instructions. Ideally I'd prefer if we'd use this opportunity to format the Core (this is just personal preference though), but as it is, the instructions are as follow.


          Step 0 - Preparation / backup.


          0.1 - For this, it'd be most advisable if you follow an existing document that can be had here:


          Best Known Methods for Installing or Upgrading the Core Server to LDMS 8.8:

          - http://community.landesk.com/support/docs/DOC-2681


          LDMS 8.1 post install backup paper:

          - http://community.landesk.com/support/docs/DOC-2343


          Both include information useful for you (and even though you're not upgrading, backing up will be a lot easier for you).




          0.2 - The most critical things for you to remember here are:

          - Backup the Ceritifcate-files (from "C:\Program Files\LANDesk\Shared Files\Keys\") along with their .0 files. NOTE DOWN the name of the cert - this will become important in a moment.

          - Backup the LDAPPL3.TEMPLATE (since you did changes to it).

          - Backup the list(s) of users in the ManagementSuite group.

          - Backup the "SCRIPTS" directory under ManagementSuite.

          - Take note of the primary account you use to launch the LANDesk Scheduler service in (it's "local system" by default - nothing is needed to be done if it's still "local system").


          - Take note of which users you use for the COM+ objects



          * Then go to CONSOLE ROOT -> COMPONENT SERVICES -> COMPUTER -> MY COMPUTER -> COM+ Applications

          * Right-click LANDesk / LANDesk1 and select "PROPERTIES"

          * In the "IDENTITY" tab note the AD-user you use.


          You don't need to pay attention to users' permissions, as that info gets saved in the DB. But you WILL need to re-add the users to the ManagementSuite group for them to be allowed to access LDMS again.




          0.3 - as a "just in case", I would recommend having a FULL backup of the Core. Better to be safe than sorry.




          0.4 - Note down the name of the database and the access details to it. I.e.:

          - Database == "MyDB"

          - Username == "Bob"

          - Password == "pw"




          1 - Uninstall LANDesk. Not much to be said here.




          2 - Preparing for the re-install...


          2.1 - Ideally, have a new, empty, temporary DB available. This would greatly ease things (I don't want any build-operations accidentally damaging something in your existing DB).


          Ideally too, this new DB/instance should have the same username/password as your existing one (this will make life easier later on).


          2.2 - Remember that I asked you to remember the name of your certificate in step 0.2 ? Please decice BEFORE the (re-)install of LANDesk what you'll call the certificate that the installer will ask you for.


          The certificate ...

          - ... MUST be unique in name. (i.e. if you called the old cert "landesk", do not called the new one "landesk" or you'll get to re-do this all again).

          - ... SHOULD be easily uniquely identifiable. I suggest using the landesk-version / date here.


          Something like a standard nominclature of "myserver_87_20081205" would mean:

          - Name of the server

          - LANDesk 8.7 was used at the creation of this cert.

          - The cert was created on December 5th, 2008 (the notation is back to front for true uniqueness).




          3 - Install LANDesk.


          3.1 - Install LANDesk to the new location (this is pretty straight forward) against the new (temporary) database.


          3.2 - Install the Servicepack and any other patches required. Don't bother activating the Core.




          3.3 - Now that this is done, "re-wire" the Core to point to your old, existing DB with all the data in it. You do this like so:


          3.3.0 - Stop all the Services on the Core.


          3.3.a - on the Core run SVCCFG.EXE (by default in "C:\Program Files\LANDesk\ManagementSuite\").


          3.3.b - Change the connection details in the first (GENERAL) tab to point to your existing database. Depending on what you get given, this may require a change of username & password.


          3.3.c - when done - press "OK". Rebooting the Core is the lazier option to re-starting all the services, but if re-starting the services will be faster, go with that. You're now talking again to your old DB.




          3.4 - Re-add the necessary users to the ManagementSuite group.


          3.5 - Change the identity of the COM+ objects for LANDesk / LANDesk1 from "LANDeskComPlus" to your AD-user (necessary so that we can authenticate against your AD).


          3.6 - Change (if needed) the primary account with which the LANDesk Scheduler runs (local system by default - you may have changed it).


          NOTE: You should *NOT* need to re-activate your Core for this, since we don't care about the temporary DB and the existing DB is already activated against the hardware it's on.


          3.7 - Restore the SCRIPTS-directory under the MANAGEMENTSUITE directory. This is not needed really, if you didn't create custom scripts.


          3.8 - over-write the existing LDAPPL3.TEMPLATE with your older copy (which has your settings).


          3.9 - in the Console, make sure to update the LDAPPL3 via "make available to clients", so that your desired changes are written out.




          3.10.a - in order to re-register your old cert with the Core, you'll need to copy the files back into the KEYS directory (unlike the LANDesk install, this is going to still be on "C:\Program Files\LANDesk\Shared Files\" ).


          3.10.b - Once the files are there, you'll need to register them via command-line. You do that in the following format:


          installkey.exe Cert-name "/LDMS=C:\Program Files\LANDesk\ManagementSuite\ldlogon"



          So - if your cert-name is called "mycert.crt" you'd only use "mycert" (notice the lack of .CRT" ... and you need to point to the correct location for LDLOGON. So for a cert called "mycert", the following command may work for you:


          installkey mycert "/LDMS=E:\Program Files\LANDesk\ManagementSuite\ldlogon"



          You can check whether this was successful by reading the "installkey.log" (which is in the same KEYS directory).




          3.11 - Also, go into EACH agent configuration you have and change / undo the change, then save it. The purpose of this is so that the respective configuration files get written out (i.e. - the MSI, the INI and so on).



          Section 4 - Database side things to check / correct.


          4.1 - the METASCHEMAS table:


          METASCHEMAS contains the locations of the various XML-files. The format is pretty simple, as you can see by running a simple:


          select * from METASCHEMAS



          All you need to do is to make sure the paths are correct. There's two possible formats - UNC and "local drive" ... you just need to correct these as needed, if the server changes name or (at least) install location.


          For instance:


          UNC example - BEFORE:





          should become:





          Local-path example - BEFORE


          C:\Program Files\LANDesk\ManagementSuite\Datamart.xml



          Should become (if we install to the same directory structure on E:\ for instance):


          E:\Program Files\LANDesk\ManagementSuite\Datamart.xml



          Having these values correct is important, as this is where COREDBUTIL reads out where the files it needs to (re-)build the database are stored.


          NOTE -- no service restart is needed for these changes.




          4.2 - the METASYSTEMS table:


          The METASYSTEMS table is of some interest to any Core, and of particular interest to a Rollup. On any "normal" Core, there should be just a single line here.


          You can see this by simply running:


          select * from METASYSTEMS



          There's several important parts here:

          4.2.a - SYSTEMNAME (this is the name of the Core) -- if the name changed, please make sure this is pointing to the right name.


          4.2.b - SYSTEMGUID -- this is likely best to be copied from the METASYSTEMS table in your "dummy" database that you used for installation of LANDesk - keeps life simpler. :)


          4.2.c - CONNECTINFO -- while a somewhat long (plain text) string, the structure of it is pretty easy to see. You MAY or MAY NOT need to update this - this is purely going to depend on whether your server / DB-server changed location. If you're unsure here, get a DB-expert in to help you out here.


          This string is used by remote 32-bit Consoles to connect to the DB (it's fed to them by the Core).


          4.2.d -- CORESERVER -- similar to 4.2.a - this should be renamed to fit the "new name" if the system changed name.


          The other fields (in particular MDVERSION) should not be touched.




          4.3 - the KEYVALUE table:


          This table will require a few (simple) changes as well - this is where most servces' settings are saved (such as the Inventory Service's settings) - very straight forward.


          Things for you to look for are / SQL for you to look at are:


          select * from KEYVALUE where KEYNAME IN ('MACHINENAME', 'CORE NAME')



          This should return:


          - APPLICATION NAME = "Agent Configuration" // KEYNAME = "Core Name" // STRINGVALUE = YOUROLDCORENAME


          The idea here is to change the STRINGVALUE for both of those to match your new Core's name (if the Core got renamed).


          This will allow Scheduler & other services to then run correctly (as otherwise they run into an identity crisis of trying to reach a server which either doesn't exist or doesn't do LANDesk anymore or - worse - still exists but should not be used).




          And that should be all. Please let me know if you've got any questions.


          NOTE -- you may potentially have to go through the NT-security on the directories again, to make sure that they are as they should be (as you have to on most Core installs in your environment).





          - Paul Hoffmann

          LANDesk EMEA Technical Lead