After the Server/Collector upgrade, the Agent bootstrap upgrades the actual Agent, but the old version Agents run until you restart your applications.
Due to a change of the license handling of .NET and IIS agents in AppMon 6.3 and later, it is strongly recommended to restart all .NET and IIS agents on a host after an upgrade from a version earlier than 6.3 to AppMon 6.3 or later.
You should have a restart plan/coordination for your application tiers.
You can find the Agent version (bootstrap and active part) information in the Agents Overview dashlet.
Yes. For example, if you have a 7.0 Server and 7.0 license active on that server, 6.5 Agents consume the license slots as with a 6.5 Server and license. However, be sure to check the general Agent compatibility.
No for most Agents, because they are bootstrapped and upgrade automatically with a restart. But check if your bootstrap version is still supported. See Upgrade Agents for more information.
We strongly recommend to also update the Agents. Note that most Agents (bootstrapped ones) will upgrade automatically on restart. See update scenarios for details on keeping Agents on the old version.
No, but it is highly recommended for backup purposes. See the tool syntax for more information.
No. Use your database backup to go back.
Connecting the new AppMon Server to the old Performance Warehouse database updates the AppMon schema. You can check the version of the DB database.
For example, in SQL Server:
SELECT MAX(version) FROM schema_version;
If there is no table
schema_version in your schema (in AppMon 6.3 and earlier), use the following statement:
SELECT * FROM dynatrace70.dbo.version;
Yes, but only the last 10 minutes. Older data is lost.
This depends on the version you are upgrading from and the amount and type of data stored in the database. In general it should be done in a under one hour, but can take up to 20 hours in very specific single worst case scenarios.
No. Submit a request for enhancement if you require this.
No, except only the last 10 minutes of data collected while the migration is running is stored.
You need to restore the backups which were made as during the execution of the upgrade guide. This means losing all data since the upgrade. This page shows details using the migration archive, Performance Warehouse and session storage backups.
Be sure that AppMon is disconnected while restoration. For the restoration, refer to your datyabase vendor documentation on how to restore snapshots.
Keep in mind that roll back should be a last resort scenario, first open a support ticket for your upgrade problem. Then open a license support ticket to get an old license.
Not immediately for regular licenses (excludes demo and POC). After deactivation, you have a grace period where the license still functions. See license deactivation for more information.
When upgrading from 6.5 and earlier, UEM volume deactivates immediately however and does not have a grace period, as the voucher with the remaining visit counts is already returned to eService. When migrating from 7.0 and higher, the volume deactivates only if it is not part of the standard license (eg vouchers), otherwise the grace period also applies for the volume.
Collector instances share one single installation directory and are started and installed with the
As these instances share certain files such as
dtcollector.ini, you should shut down all instances when migrating files. The migration tool migrates all files for all collector instances by default, so you don't need any special parameters. But you must make sure all instances are started from the new location using
init.d scripts or installing new Windows services (as described in the guide).
Yes, this is supported, as long as the target operating system is supported by AppMon in general. As part of the migration you move the migration archive from one system to another.
The default paths in the configuration are relative paths, so these work independent of the OS. If you manually changed relative paths to absolute paths, you must change them after the migration.
It is recommended that you do not migrate to another system and upgrade to a new version at the same time, since this makes it more difficult to isolate potential post-migration problems. In these cases, it is recommended that you first follow the guide to migrate to the new operating system, check that everything is working, and then upgrade to the new version.
Check if UEM license is imported and has remaining available visits.
If ok, try to disable LZW encoding, by switching to debug mode with CTRL-SHIFT-F9 and going to:
System Profile > <application> > Advanced Configuration > Configure Advanced Events, and select the Disable LZW encoding of the beacon checkbox.
If this does not help, re-enable LZW.