cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Client migration from 6.1 to 6.2 workstation names

We are in the process of upgrading from 6.1 to 6.2 and need to gather the workstation name of the dt 6.1 client to push out the 6.2 client to all the desktop.. Is this data stored as workstation or ip address? Who can gather this information?

24 REPLIES 24

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Hi Mike

When your Dynatrace 6.1 Clients connect to a Dynatrace 6.2 server they will automatically be updated. There is no need to push out the update. your users will get a notification saying: A new client version is available -> do you want to upgrade?

Does this work for you?

Thanks Andreas for getting back with me the only issues with that is we have 3 environments so if we allow it to update to 6.2 in a control rollout of 6.2 then we wouldn't be able to connect to our 6.1 environment. Thus the reason behind pushing a 6.2 client..

I understand. Well - good news is that you will be able to connect to a 6.2 enviornment even with a 6.1 client. you can instruct your users NOT to update to the 6.2 version until all the servers they connect to are upgraded

the option option you have is to parse the dynatrace server log file for the user logins. you will not get the workstation names but the usernames of people that have logged in. I assume you can then correlate usernames to workstations

Andi

Andi - In the past we could have multiple versions of the client installed to accommodate upgrades, but if there's now an auto-update between versions, how do you suggest we roll an upgrade through our SDLC under this new model? I really don't want to just instruct the users to "ignore the annoying upgrade message" until we've completed the full implementation (which may take 2-3 months).

Thanks,

Mick

Sorry if I caused any confusion. You can still install multiple versions of the dynatrace client on your system. You can install 6.1 next to 6.2. You just need to make sure you use the full dynatrace client installer. I guess that is where your initial question actually starts. How to push out these new clients to your users.

Well - you can look at the server logs to figure out who connected to these servers. Then you can send them the dynatrace Client - or even easier -> just send them the link to the Web Start Client. Every Dynatrace SErver automatically hosts the Dynatrace Web Start Client. Clicking on that link will download a client EXACTLY for that dynatrace server. The Client will also only connect to that server which avoids any version conflicts as only this client will upgraded in case you upgrade the server

The way I see it you have two options therefore:

  • Let users install parallel versions of the full dynatrace client and tell them which client to connect to which servers
  • Let users use the Web Start Client instead of the fully installed version

Andi

Thanks for responding Andreas, The only issue that I see is if the 6.1 client is connected to the 6.2 server it will prompt for an upgrade. Can the prompt to upgrade be suppressed? My original though was to install the 6.2 client and leave the 6.1 client. That way when the 6.2 client is used it could only connect to the 6.2 enviroments that I have migrated and the 6.1 client can continue to connect to the 6.1 environment.

You can disable that update check on every client machine. in the Client Settings Menu you find a checkbox called "Check for client updates"

Andreas one more question. Will the 6.2 client upgrade to the latest release? We have a package made with 6.2.0.1239 client and looks like a new release on the website now of 6.2.4.1057. Will the 6.2.0.1239 update to the new version once it connects to the server with the latest fixpack?

If you install 6.4.x on your dt server and then connect your dynatrace client to that server it will prompt you whether you want to update your client to 6.4.x. If you select YES it will update

Andi

Andreas when running the dtmigration tool on the collector I'm getting java is not recognized. suggestions?

The Migration Tool is a Java Tool. You need to have Java installed on your machine in order for the tool to work. You can download JAva from the ORacle Download Page. Simply google for Java Download and download a Java Virtual Machine. Alternatively you can use the JVM that is installed with dynatrace. The JRE is installed in the Dynatrace Installation directory under JRE/BIN. You can therefore add this full path to your Windows PATH env variable. with that the migration tool should be able to find java.exe

Andi

Good suggestion Andreas.. I successfully migrated our development environment today. Thanks so much for all the help.. The only thing I see that might be an issue is "no uem volume available" so I reached out to me sale rep to see if he can help.. Any suggestions??

It sounds like you need to upgrade your volume and re add it

I didn't see an option to upgrade and re add volume.. So would I need to deactivate then reactivate?

in eservices you will need to upgrade your UEM voucher and then re-add it. it should have been deactivated when you upgraded your license

Another option to Andi's suggestion above it to use a portable version of Java... Search for JPortable (third party tool and in no way associated with dynatrace)

Andreas is it possible to stage the migration from 6.1 to 6.2? Can I install 6.2 with 6.1 running? Configure 6.2 run the upgrades to get the latest version? Then stop 6.1 services and run the migration tool and connect to the performance warehouse? Can I do the same on the collectors?

YEs you can. Just make sure that you dont run into any port conflicts as 6.2 by default will use the same ports. There are options to use different ports which allows you to run both side-by-side

Andreas after migration I've noticed several of my agents that are running 5.6.05802 bootstrap and version 6.2.4.1057. What does it take to get the bootstrap up to the right version?

You would need to install the latest version of these agents on these machines. The dtagent.dll is the actual "bootstrap" agent. That dll stays on that version until you update it on that machine.

Andreas thanks so much for all your help.. I migrated our test environment today which is 10 collectors and one dt server. after the migration some of the agents was disable after the collector was migrated. The following error message. "Connected (issue: Instrumentation was disabled during agent runtime. The Collector runs low memory). I have 4 collectors each running on VM's 2 instance per collector in one collector group. With 203 web server agents and 357 .net agents connected.. I migrated 2 server at a time in the collector group. This concerns me as next will be my production environment and getting application admin to restart agents isn't a good option.. My plan was and still is to make the migration seamless but if agent restart is the only way I will need to rethink the migration. Can you offer some guidance.. Is this from too many agents connecting to the collector at one time?

Hi Mike. The agent restart should not be necessary. To make sure you didnt miss any step in the upgrade process or any best practices I suggest you open a ticket with our support team. they can have a look at your environment and tell you how to best upgrade.

Andreas what about multiply collector instances.. When you run the dtmigration tool on the collectors will it get cache for both collector instances?

Hey Mike,

if your Collector instances are on the same installation / machine (which instance sort of implies) the migration tool will catch all the caches,...

If you have Collectors on several machines you need to apply dtmigration to each of the machines separately.

You could have Collector instances beyond the default instances on each machine (configured to listen for Agents on different ports). The tool always catches all default and extra instances of an installation.

Re staging:

I just checked License Upgrade - Trial License (three weeks). This should give you a good opportunity to stage things.

Re Clients and different Server versions:

Much too much already said. My no-brainer for such a diverse scenario would be

https://<DynatraceServerName>:8021

(Webstart Client) for practically everybody.

Hope that helps

G.