Automic Workload Automation

When we first acquired the product and were running V9 of the Automation Engine, we called our servers UC4PROD and UC4DEV.  Then we upgraded to V11, and we called our servers UC4PRODV11 and UC4DEVV11.

Now I need to stand up new servers for V12.  I could follow the same name pattern, but I'm thinking I should stop using the "UC4" term.  Should I replace it with "AWA" for "Automation Workload Automation"?    "AE" for "Automation Engine"?  Should I keep using "UC4"?

What do you call your V12 servers?

UC4LIFE

I needed that!

petwir, if you are referring to the servers hosting the AE, can't you just use the Hostnames?

/Keld.

Hi

We named our UC4 Systems [Department]UC4[ENV] – GMUC4U, GMUC4P, …

OS Servers [Department]UC4[ENV][ascending number] – GMUC4U1, GMUC4U2, …

My personal systems (temporary sandboxes) usually are V112, V12, V122,…

Do you really want to follow the permanent name-changing-iterations?

In this case you need to rename them all 6 Months.. J

Let me brainstorm that for you:

• SBB “something”
• UC4
• ONE-A
• AWA
• CA-AWA
• CA-AWA-A-BROADCOM-COMPANIES-PRODUCT
• CA-AWA-A-BROADCOM-COMPANIES-PRODUCT-SOLD-TO-XYZ
• ....

Cheers, Wolfgang

Hahaha

Our UC4 Systems are called UC4 followed by a letter indicating the env., so my Production system is called UC4P.

This name is never going to be changed.

I have created DNS entries for all my AE servers. So in my Production system I have 4 AE servers and they have their own DNS entries, UC4P1, UC4P2, UC4P3 and UC4P4.

The DNS entries are also referred to from other places, such as in ucsrv.ini and in UC_SYSTEM_SETTINGS, key WP_MIN_NUMBER.

Using DNS gives me the flexibility when migrating from one OS version to the next, e.g. as in right now where I'm migrating from Window Server 2008 to Windows Server 2016. I just need to shut down the Engines, change the DNS pointer and then bring up my AE on the new servers.

On other benefit is that all our agents (we do have more then 10.000 agents in each UC4 system) are also connecting to the DNS entries of the AE Servers, e.g in the agents ini file I have added cp=UC4P1:2217.

/Keld.

When I originally built our system I called it BXLT_QA or BXLT_PR.  I thought I got around the whole UC4 / Automic / CA / Broadcom thing, but then we were aquired by Shire.  I wasn't too far along in my build out so I renamed the systems to SHIRE_QA and SHIRE_PR.  But now we were just bought out by Takeda.  I am not changing them again.  

I don't know what the answer is.  Things are always changing on both sides (customer & vendor).  

What about ENT_QA or ENT_PR?  For Enterprise?  

When we did a version upgrade in parallel from v3 to v5 and at that time it was known as UC4 Global, we named the new system UC4G5 and due to the pain involved of setting up a parallel system, we have kept the name since and will continue to use it.

jkessans - I'm about to embark on upgrading from V11 to V12 and am reading through whatever posts I can.  I just read your response here and I'm wondering what pain you experienced during the setup of a parallel system.  I have, to date, only done in place upgrades, but it looks like now I'm going to need to do it in parallel.  Any lessons learned or any information at all here?  

We've decided our V11 to V12 upgrade will be in place.

We did a parallel upgrade from V9 to V11 in 2016.  But we hired a CA/Automic staff person to assist us.  He knew the ropes and basically lead us by the hand through the whole process.

He knew the proper steps for standing up V11.   He was able to set up parallel remote agents to communicate with V11 by using different ports.  The first thing to bring over was an export/import of user groups.  Then an export/import of users.  Then we applied our V9 settings to our V11 client 0000, which was done by manually reviewing one-line-at-a-time the contents of many of the important UC* variables.  Then we transported our solutions.

It was nice that on cutover day, it was literally just turn off V9 schedules and turn on V11 schedules.  However we also lost our run history, so we had to keep the V9 server around for access to that history.

Edit1:

Our motivation for the parallel upgrade was to upgrade the WindowsOS.  We also had to make sure the AE server, where we run our FTP agent, had the same outward facing IP address so our SFTP connections would not break.

The last time we did a full parallel upgrade was that v3 to v5 back in 2007.  Since then, I have done in place upgrades due to the number of agents we have in our environments.  Now I have read on the forums other ways to get around that and will look into it for a future upgrade. 

Our last upgrade from v10 to v12.0, we also had to upgrade our servers from Windows 2008 to 2016.  I installed v10 on the 2016 servers using temporary server names and validated that I had everything configured correctly.  On the day of switchover, we brought the system down and the new servers were renamed to the previous names along with keeping the same IP addresses.  That way we were only making one significant change in the environment.  

We were on Windows 2016 for almost 5 months before we then upgraded to v12 in place.

Edit: I should add that we did do a partial parallel system installation early last year when we hardened our environment.  In the past, we had most of non-production clients on our production system and we split them off into their own system.  We stood that whole non-production environment up in parallel with the additional installation of duplicate agents pointing to the new system.  It was a slow process as with the number of agents needed.  When it was time to migrate those non-production clients over to the new system, we just copied the database and then only started those non-production clients and deleted copied production clients from that system.

Thank you everyone for sharing.   We know that predicting future directions is an impossible task. 

The final decision here will be made by my supervisor, and I think we will probably lean towards the best practices we've applied to some other vendor products.  Our server names should indicate at least three things; (1) product (2) environment (3) a meaningless sequence number to support either in-place upgrades or parallel upgrades.   And I agree that using DNS names makes a lot of sense too.

And I suspect we will continue to call the product "UC4" through the next upgrade.

Late to the party, but want to share.

As for host names, the company dictates that they resemble an explosion at the ASCII factory. There is a system behind them, but they might as well come from /dev/urandom.

As for node names in ucsrv.ini, UC lives on. Our nodes still have "UC" in the name and a numbering scheme.

As for what I call them in daily operations, I call the servers <censored> and ********************* respectively

And should you want to be more future-proof than we are with the naming, may I suggest going system and company-agnostic? Something like jms01 (job management system 01) might carry meaning through any further acquisitions.