-
Title
Webinar: How to upgrade Desktop Authority Jan. 31, 2018 -
Description
This article includes the Webex and audio recording from the "How to Upgrade Desktop Authority" Webinar delivered on Jan. 31, 2018 covering the upgrade process and best practices.
This webinar was created to upgrade Desktop Authority to version 10.1, however the process to upgrade to version 11 is the same.
-
Resolution
"Companion Document" information listed below:
NOTE: Support for Desktop Authority (DA) 9.3 was discontinued February 7th 2018.
Support for DA 10.0 and DA 10.1 will be discontinued March 22nd 2019When support is discontinued for an older version there will be:
• No new patches or fixes supplied for that version• The download files will be removed from the support portal• Any future technical assistance for that version will be limited to providing information on how to upgrade to a supported version.Desktop Authority Download
To upgrade Desktop Authority you need to at least be on version 9.3. Versions of Desktop Authority older than 9.3 cannot be upgraded directly to to the newer version.The upgrade path shows the order of operation when upgrading from older versions. 8.1.2 > 9.3 > 11.x
WARNING: The Microsoft Windows Attachment Manager routinely blocks files that have been downloaded from the Internet. A zipped archive (or a self-extracting executable), which is blocked will also stamp all files contained in the archive as blocked when they are extracted. Blocked files can create many undesirable consequences at runtime. Therefore, it is important to ensure that any files originating from the Internet are unblocked prior to extraction or execution. See KB 262298 for instructions.
License File
IMPORTANT: In order to upgrade to version 11, you must obtain a new license file. (9.X and 10.X licenses will NOT be compatible with version 11)
To obtain a new license file, please refer to the Licensing Assistance page on the Support Portal.Quest recommends that you plan to upgrade your product to version 11 to continue to obtain all future product features and functionality. To determine the current support phase of your product, please refer to the KACE Desktop Authority life cycle table.
We apologize for the inconvenience this issue may have caused.
Backup Data
You should always perform a backup before installing any product upgrade in order to assure a successful recovery should your upgrade fail for any reason. In addition to backing up the Desktop Authority databases the DA profiles can be exported as additional level of security. This is not a required step, but it is recommended. If there are any issues with the database backup. A new database can be created and the exported profiles can be imported directly into the console.Antivirus ExceptionsFinally as a last step in preparation you should update your Anti-Virus Exceptions. Due to product re-branding most of the file paths have changed. Make sure to update your Antivirus exceptions so that the new locations are excluded. The technical article that has the updated file paths will be included in the Companion document.
Antivirus Exceptions File List
System RequirementsAll of the System Requirements can be found in the Installation and Upgrade guide.A few items that are important to note are:- Windows XP, Vista, 8.0, and server 2003 are no longer supported. The client will not install on these versions and the Validation Logic options have been removed. You can also no longer install or upgrade the DA console on Server 2003.
- SQL 2005 is no longer supported. Supported SQL versions are 2008-2016. If on SQL version 2005, SQL either needs to be upgraded or the database need to be moved to a supported version.
- Domain Functional Level now needs to be 2008 or above.
Alternative Upgrade Options
When planning your upgrade it’s important to note that there are some additional options other than doing an in place upgrade on your current Desktop Authority server.- You have the option to do a migration to a different server.
- You also have the option to install the new version of DA on another server independent of the current installation.
Migration
With a migration there are two options each with different steps.- The first option is to migrate DA to a new server when SQL is installed on a secondary server.
- The second option is to migrate DA to a new server when SQL is installed on the same server as the DA installation and needs to be migrated as well.
When migrating using a secondary SQL server there is no need to move the DA databases. All that needs to be done is stop the Desktop Authority Operations and Manager Services on the current DA server then Install DA on the new server. During the install it will ask if you want to use an existing SQL Server Instance or create a new one. Choose the option to use an existing SQL Server Instance. The upgrade will see that the DA databases already exist and upgrade them.If SQL is installed on the DA server and needs to be migrated as well then backup the current DA databases and either install SQL on the new DA server and restore the databases there or restore the databases on an existing secondary SQL server.
The most important point is that the Databases are moved prior to running the install so that the DA upgrade process can find the databases and upgrade them.
Alternate Configuration - Side by Side/Parallel/Member ServerIs what we call a new installation that is installed and configured on the same domain as an existing installation of Desktop Authority.The main reason this would be done is to test the new console and client prior to doing the actual upgrade on your production servers. This requires some additional configuration steps so that the two installations do not interfere with each-other.A standard configuration is simply an installation of the management console to a member server and then hosting the Desktop Authority services and the Desktop Authority files out on the domain controllers.An alternate configuration is an installation and configuration that does not rely on the use of domain controllers. This allows you to evaluate the newest version of DA on your production environment without adversely affecting your current version of DA. An added benefit is that you can rollout the newer version more slowly to your clients.- Previous or current settings: If you want to use your current settings, you can follow the migration instructions to restore the DAConfiguration database from your current server to the new server and install the new console against that restore point. You could also create new settings and forego the migration and use new settings until you upgrade the main server.
- File location: The replication target can be one or many locations. It can be a DC, many DCs (maybe another share on a DC), a member server, many member servers, a hybrid of both a member server and a DC or many of each.
- Script assignment: The assigned script runs after authentication. Immediately after authentication, the logon script assigned on the profile tab in Active Directory for that user’s account will execute from NETLOGON or from the specific UNC that is entered on the user’s account. The script can be called from a specific server or from the default NETLOGON share of the authenticating server.
- Script location: The script can reside only in the file replication target that you are replicating to or can be in multiple locations. It might also be different names such as ABC script in NETLOGON calls SLOGIC on a server.
- Services location: Typically the DA Administrative and Update Services are going to be installed on the same servers that house the logon script. However, there are exceptions where the services may be located and installed elsewhere. The sitemap configuration tab in the DA console contains specific settings regarding where the client should attempt to locate the services. The sitemap is extremely versatile.
- Redundancy and high availability: Files and services on DCs provide natural redundancy but there are a number of solutions that can be employed both for location of the scripts and for the server(s) to locate the services on. Locating single logon scripts with built-in logic for locating specific servers to run the script from based on the authenticating DC is a good strategy regarding redundancy and high availability. (for example: MyScript.bat in NETLOGON calls the SLOGIC script from member server 1 if the user was authenticated by DC1 and if MS1 is available – otherwise it goes to MS2).
- Computer based: The computer based settings in DA allow the client machines to be managed independent of a user logon. By default, the CBM client will automatically locate its computer settings from a SYSVOL\Policies subfolder, but can be instructed by a simple registry edit to locate them in an alternative location. The choices are up to you.
- DA GPO: We recommend not using the DA GPO for provisioning clients in a parallel Installation environment in order to avoid cross-contamination issues. The DA client provisioning GPO is a machine based GPO with only one name, so multiple instances cannot be run.
Example: If we currently have a version of DA running on our production environment. We have our domain controllers listed in that console and we plan to upgrade at some point in the future. But for now, we just want to do a fresh installation of the latest version of DA as an isolated, parallel installation that will not adversely affect our current version of DA or our settings.
We perform a fresh installation of the latest version of DA to a member server and create shares on it for user based scripts and computer based scripts, respectively (i.e. share names are UBM and CBM). We then add the member server itself to the list of servers in server manager. We install the DA Administrative Service to the member server only. We then edit the properties of the server and change the replication targets from NETLOGON and SYSVOL\… to UBM and CBM (permissions should be set similar to NETLOGON and SYSVOL on the domain controllers).
Change the logon script name on a user’s account in Active Directory from SLOGIC to the new path (\\MACMS1\UBM\SLOGIC). Or to CALLSL running out of the NETLGON share which calls the script from this particular member server. If desired, set the Machine_Sysvol_Path registry value to alter the location that the computer based settings will load from (\\MACMS1\CBM). A user based registry element from the logon script may be used to set the value. Logon as the user to test.
If you would like to request future Webinar content, please visit the Ideas section of the DA forums. If someone has already suggested your idea be sure to up vote it so that it gets moved to a higher priority.