This article stems from various good and bad practices that LANDesk support runs into - the intention here is to warn and inform our users of good as well as bad behaviours. This is a living document and will likely see quite considerable additions (commentary is welcome), as I'm pretty sure I've forgotten a lot of things to be mentioned on the first run .
Chapter I - Things you SHOULD do:
I.1 - Take a FULL backup once you've installed + service pack'ed the Core
Many people forget to do this - a "baseline backup". Once the Core is installed and service pack'ed (as applicable), it's very much recommendable to take a full backup of the Core and the Database. This permits a very safe rollback point if necessary.
I.2 - Make sure you have a backup of the right things
Please make sure you read this document - yes, it may be older (written for LANDesk Manamgement Suite 8.1 at the time), but the information is still accurate and a good guideline:
I.2.a - How to Import and Export Distribution Packages and Delivery Methods
I.2.b - LDMS 8.1 Post Install Backup Whitepaper:
The important parts in this document are to make sure you've got a full backup of your certificates, and that any new Core MUST have uniquely named Certificates.
NOTE: One important note on the certificates is that the Core Server has gained an additional certificate file over the years (this is also stored in the KEYS-directory). So the complete list (at the time of writing) up to LANDesk Management Suite 8.8 would be:
- keyname.cer -- this is the new one
I.3 - Something I've forgotten I'm sure
Chapter II - Things you SHOULD NOT do:
II.1 - We strongly discourage installing any other tools on the Core server.
The only exceptions to this are
- Your preferred Antivirus software (for obvious reasons).
- Potentially your DBMS (Database Management System), as some Core's also host the DB locally.
Mainly this is for two reasons.
II.1.a - Reason 1 - performance.
The LANDesk Core Server sees usually a pretty high I/O usage - for disks, CPU and memory, so any additional server-side app is going to compete with that. While "not recommended" this on its own is still quite reasonable.
Interestingly enough, this is actually the lesser of the two reasons. While this may cause the Core to reject connections, or be slow, it doesn't actually "break" anything if "performance" is all that's being competed for.
II.1.b - Reason 2 - Cross-application compatibility.
This is PARTICULARLY a big problem for all things related to WebConsole related components. These would be:
- IIS itself
- Anything to do with ASP.NET
The problem here comes in the form that most applications (LANDesk included) which use IIS tend to re-configure IIS in such a way that it works in the way the specific application needs it.
The problem comes from the fact that there's very few (if any) applications that use the same settings / decisions, on any of the many different settings for IIS / COM+ / ASP.NET.
So what normally happens when you have two (or more, in rare cases) such products installed on a single server is that - usually - neither ends up working. For example, LANDesk support has had many experiences with Microsoft SharePoint being a "one step process" to utterly rendering a Core Server useless (and requiring a reformat).
This is not a criticism towards Microsoft SharePoint breaking LANDesk (or any other IIS-centered application for that matter) - not at all. The important point here is that both "configure IIS their way" and as a result, in the 'best case scenario' the latter install works, while the first does not. In the worst (and more common) scenario, neither application works fully, or at all.
II.2 - Specifically, don't install Microsoft SharePoint on your Core
Please see II.1 for detailed reasons on this. In short, it pretty much will kill your Core Server.
II.3 - Don't use a bad naming convention for Certificates
A common mistake is to use a name like "LANDesk87" for a cert-name when you're installing - for instance - a LANDesk ManagementSuite 8.7 Core Server.
Why is this bad? Well - if it should be necessary to (re-)build another / an additional LANDesk server of the same version (say, because your organisation expanded, requiring a 2nd Core and a rollup), there's a high chance that this other Core will have the same (or similar) Certificate name.
The big gotcha is that certificates MUST have a unique name ... while the hashvalue.0 files may well be different, they're both pointing to a filename ... and if there's a mismatch between the public and the private keys, your certificates are essentially useless. This is particularly a problem for clients who may need to have certificates from both cores.
It's far better to decide on nomenclature up-front - some things to use would be among the following:
II.3.a - Date. This is very good, as this is very much going to be unique from Core to Core.
II.3.b - Core Name / Location. These should be used as additional identifiers, not single identifiers.
II.3.c - Organisation / Department. Essentially, just a variant of the options II.3.b.
II.3.d - LANDesk version installed. Should ONLY be used as an additional differentiatior
And so on.
So a good certificate name would be for instance "20080625_Milan_88" would for instance for a LANDesk ManagementSuite 8.8 Core Server, built in a Milan-office, on 25.6.2008 -- a nice, and good unique file-naming convention, which is going to great lengths to minimize problems with certificates in the future.
II.4 - Don't rename your Core:
Renaming a server is OK as long as it is done BEFORE IIS is installed (and thus, before LANDesk is installed). If you should "have" to rename a LANDesk Core, it's far safer to just reformat it. Renaming a system breaks IIS - while "IIS alone" could be fixed (though this requires a fair bit of work), the IIS + LANDesk combination is essentially not realistically going to be fixed (or if it is, it'll cost several times the amount of time it would do of setting up the Core anew).
NOTE: When "changing names" of Core Servers, IIS is NOT the only thing to be considered. A Core is keeping track of "itself" in various places - registry and database as well - which will cause additional problems.
NOTE: If "all you do" is wanting to move DB from "old Server A" to "new server with a different name" then this is quite fine. It will simply require a bit of editing in the database tables. Please contact LANDesk support for details and help in this regard.
Thanks to Mark Star for this reminder
Whilst the advent of Windows 2008 R2 and IIS 7.5 has helped IIS considerably here, this still can (and does) cause a considerable quantity of problems, even with the new way in which IIS 7.5 handles the IUSR account. As indicated above, IIS is just part of the equation, it's still a bad idea to rename a Core.
II.5 - Don't use your Core Server as a PXE rep:
While this may be OK (often out of necessity) for test and/or demo-environments, it is very much advised against using a Core Server as a PXE-rep for OSD.
Please use a separate system as a PXE-rep (either client or server, doesn't matter much).
II.6 – Regarding the .NET Framework:
Please ONLY ever install the version of .NET that the LANDesk Core requires. The exact version that’s require depends on your version of LANDesk Management Suite that you use (for example, whilst Management Suite 8.8 requires .NET 2.0, the Management Suite version 9.0 requires .NET 3.5).
Whilst it’s OK to install security updates for THAT particular version, it is *NOT* OK to install a newer version (i.e. – whilst .NET 3.5 is OK for Management Suite 9.0, do not assume that .NET 4.0 is as well).
.NET is not just something that should be installed or updated just “because it is there”. A new version of .NET has a great chance of breaking a considerable part of the ManagementSuite and has historically been full of potential to break things.
Usually the most common impacted components are:
- Software Distribution (often everything related to Scheduled breaks)
- WebService related items (Patch Management, Policy, etc.)
Unless a version of LANDesk specifically supports the version of the .NET Framework you intend to install, please do not upgrade versions.
II.7 - Don't install Microsoft Window Server Update Services on your Core
DOC-27351 Please see II.1 for detailed reasons on this. In short, it pretty much will kill your Core Server.
Chapter III - Changelog
Version 1 - original release.
Version 2 - added section II.4 - Don't rename your Core:
Version 3 - Added Changelog. I've got a feeling this could grow quite a bit - the idea is that this should be a single-stop to all the most important things that are very good / very bad practice in regards to Cores.
Version 4 – minor changes / corrections to spelling
Version 5 - Added the section about .NET in - II.6 – Regarding the .NET Framework:
Version 5 - Added some information relating to IIS 7.5 // Windows 2008 R2 to - II.4 - Don't rename your Core:
LANDesk EMEA Technical Lead