Windows Jobs

[pavan shashikanth guddeti]

Hi All,

We do have a Scenario where we needs to run jobs on their Logins .

We do have around 4 logins related to micro strategy and they runs on Windows Agent .We needs to run the Workflows based on the login .Where we do have around 200 objects which runs on these 4 logins only .But around 80% runs on 1 login and rest of the 20% Workflows run on other 3 login.

Earlier it is used to be of Single login to run all the Objects but now due to Security issue we are planning to Segregate them.

Can Some one help us out here for this issue where all our 200 objects are in production and it is manual effort to change individual one.But we use the common job for all the 200 Micro strategy jobs.Can we know if there is any way to create a promptset to pick the correct login for that Workflow ? or any other Alternative ?

[pavan shashikanth guddeti]

Hi All,

We do have a Scenario where we needs to run jobs on their Logins .

We do have around 4 usernames related to micro strategy and they runs on Windows Agent .We needs to run the Workflows based on the login .Where we do have around 200 objects which runs on these 4 logins only .But around 80% runs on 1 username and rest of the 20% Workflows run on other 3 usernames.

Earlier it is used to be of Single login to run all the Objects but now due to Security issue we are planning to Segregate them.

Can Some one help us out here for this issue where all our 200 objects are in production and it is manual effort to change individual one.But we use the common job for all the 200 Micro strategy jobs.Can we know if there is any way to create a promptset to pick the correct username  for that Workflow ? or any other Alternative ?

[Carsten Schmitz]

Hi.

​This is frankly a really confusing post and I do not understand the question, or how it even relates to Automic.

But you may want to look at the "runas" Windows command, you can use that to switch effective users for Windows command line jobs.

You can (as per documentation, I didn't try this myself) also change the LOGIN object for a bunch of objects in bulk. The attribute is called LOGIN, and the way to do bulk changes in Automic is to export the objects via Transport Case, change them via ucybchg utility, and import them back via Transport Case. This way you can change the login/account being used by the job by substituting one LOGIN object for another, in bulk.

Best regards.

------------------------------
These contain very good advise on asking questions and describing supposed bugs (no, you do not need to go to StackExchange for Automic questions, but yes, the parts on asking detailed, useful questions ARE usually relevant):

http://www.catb.org/~esr/faqs/smart-questions.html

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I will not respond to PM asking for help unless there's an actual reason to keep the discussion off of the public forums.
------------------------------

[pavan shashikanth guddeti]

Hi Carsten,


I didnt posted question in proper Sentence.

In our case we login to the Agent server with "User WindowsA" (It is defined as the Login Object), post that all the MicroStrategy jobs are executed with "User MSTR1" (which is defined on the MicroStrategy job) that is a MicroStrategy standard account. What we are now looking is for all our jobs to run with 4 different MicroStrategy users … like  User MSTR2, User MSTR3 and User MSTR4.

Where MSTR1 will run 80% jobs and rest of the Accounts run 30% jobs

[Carsten Schmitz]

Hi Pavan Shashikanth Guddeti,

thanks for clarifying that​. This means my advise stands as written.

As I said, if you want to run jobs with four different user accounts on that same agent, four LOGIN objects is likely the way to go (you can not have two Windows logins for the same server in a LOGIN object). So put one account into each LOGIN object, and configure your jobs to use the required login object.

If you need to bulk update the jobs to use new LOGIN objects, the method of the Transport Case and ucybchg Utility is the only officially supported way. Writing to the database to change stuff is discouraged. If you only need to change 30% of these 200 objects you mentioned, I'd probably just change them in the interface.

Hth,

[pavan shashikanth guddeti]

Hi Carsten,

Our "User WindowsA" is known as Enterprise Account as XXX\Pswd (which is related to Agent connection to OA) While we are Executing the Workflows they run on the Standard Account which were at MSTR Server level and it will checks that Standard Account to run the System manager Workflow.

But i am assuming in my Scenario we cant create multiple login objects where we do have one Enterprise Account which got installed where as the Standard Accounts are related to MSTR Server level.

Can you please correct if I am wrong in understanding your point ?

[Carsten Schmitz]

​Hi Pavan Shashikanth Guddeti,

I am unfortunately not very familiar with some of the terminology you use, I don't know what the MSTR Server (level) is. Regardless of the details (no need to explain), if you can't separate the users in LOGIN objects, you can always use "runas" on the Windows server to launch the actual executable with different accounts.

Beyond that, I'm afraid I won't be able to offer specific assistance as I am not familiar with your particular setup.

Best regards,
Carsten

[Angus Reid]

Ok so a lot of jobs need to be segregated and run as different accounts and be easily identifiable. Easy enough if using Dollar universe so will suggest a possible answer with that.​

• Install a $U node onto the host
• Create separate Submission accounts in $U on the node 1 for each of the desired accounts - the accounts can be Windows
• Create 4 MUs -  for each of the set of processes - associate a submission account with each MU i.e. MU=PROD1 user=Prod1
• Create Uprocs to call the scripts - 1 uproc for each process
• Schedule each processes (now a uproc) against the corresponding MU and thus user

Outcome should be processes grouped by type in an easy to maintain and update schedule.  This will provide visibility of the processes and remve security issues as that would be controlled by $U now and not individuals.

[pavan shashikanth guddeti]

Thanks Reid,

for the quick response.

Can i know how it can be done in One Automic Version 12.0.1(we are in this Version).

And we do have one Agent and it consist of 4 Different accounts on that agent.So can we have a solution for it.

[Angus Reid]

​Anything that can be done in $U can be done in One Automation.

It is possible to associate processes with users in One Automation in a similar way to $U and get the same outcome.  Same with creating processes so they can be segregrated.

[pavan shashikanth guddeti]

Thanks Reid,

Can you please help me with below 2 points as I am unable to understand them.

1)Create Uprocs to call the scripts - 1 uproc for each process
2)Schedule each processes (now a uproc) against the corresponding MU and thus user

[pavan shashikanth guddeti]

Hi Reid,

I didnt posted question in proper Sentence.

In our case we login to the Agent server with "User WindowsA" (It is defined as the Login Object), post that all the MicroStrategy jobs are executed with "User MSTR1" (which is defined on the MicroStrategy job) that is a MicroStrategy standard account. What we are now looking is for all our jobs to run with 4 different MicroStrategy users … like  User MSTR2, User MSTR3 and User MSTR4.

Where MSTR1 will run 80% jobs and rest of the Accounts run 30% jobs