why does no one know what account is acting as the local admin ?
is the rscd install being done manually ?
are the servers in a domain ?
what is your 'onboarding' process ?
Bizarre it may sound but this is what I have been told. There seems to have been no inventory which could provide me this piece of info.
We have a legacy product which is performing the agent installation on 2003 and 2008 machines, it uses AD account which is forced via group policy. For 2013 servers, agent installation is a manual task.
All servers are in domain, there are no standalone servers.
There are a few ways of fixing this:
1. Standardize the admin account across the whole environment and define which is supposed to be used, but that can take a while and wouldn't be that simple.
2. Create a new, dedicated local admin account on all servers to be used for the BSA agent. This would be my preferred method, because it's always good to have a dedicated account for audit purposes. When something bad happens on a server and the admin account pops up in the event logs, fingers will be pointed to BSA and you won't have any ways to tell if it was or wasn't it unless it always runs with a specific account that nothing else uses.
Option 2 is the best practice. You should never use an all-purpose admin account for BSA.
Does the legacy product have the ability to run scripts and parameterize the msi install command for the agent ? if so you can figure out the local account and update the msi command to use the right one.
Yanick, thanks for your feedback. Agree point 2 is how it should be done and I am exploring that option. I just don't want to get stuck in the process and is therefore looking for other alternatives as well.
Bill, I will check compatibility of running the msi file with parametrized option. Are you suggesting I figure out the localadmin account name and pass this value to MAPUSER option because looking at the documentation, value passed to MAPUSER option will be used to update the exports files and we should avoid making user mappings in exports files.
For the initial setup that can be ok, if you can then immediately push acls to it.
looking into your problem there are few ways of doing it and as earlier suggested by bill and yanik
lemme jort down into points and solve this issue
1. the document in BMC never says that only one account id can be mapped so the mishap happened in my reply to you earlier in the day
There are ways to fix this by
1. do you have ADDM or any discovery tool in your environment? if so get the report of all the servers having these two users AAA,BBB and filter it out. if you dont have ADDM or any discovery tool you better to use the existing tool with the help of powershell to fetch the report of all the servers having the user AAA,BBB
2. When you try to enroll the servers in console you set the property of admin_account part of the enrolling procedure (Importing the servers )so that it can have all the details being part of the enrollment procedure.
hope my few cents also helped you
PS: As Yanik said its recommende to have a dedicated user specifically for bladelogic to avoid mishap in future so being part of the installation its recommend to write a batch script to create the local user and then install and map it accordingly and then later enroll the servers so that it can avoid many issues in future regarding enrollment procedure.
Try this and see if it helps
Create 2 roles (Role1 and Role2) and map both to BLAdmin user.
Not modify users.local file on all targets where agents are installed with the following line
1. Now create a list of all the csv servers and also add a property say Admin Name Value: Admin One
2. Login to BSA Console using BLAdmin and choose Role 1
3. Try importing the entire servers using the csv file created
4. Capture the list of servers where it failed, this would give you the list of server where we have DevAdmin
5. Now run the same job using Role2 Modify the property say Admin Name Value : Dev Admin
This way you have all the servers added to the group
And the property will help you track the server or create smart groups accordingly.
Now use Push Acls and manage. Or use the BSA to add the same user on all servers
Thanks Srikanth, I was also thinking of implementing something along same lines.
Let me work on it and provide you'all an update. Thank you everyone.
I think it is good practice to create a server property something like ADMIN_USER with a default value of your normal renamed administrator account or if as Yanick suggests you have a dedicated account for BSA use that account name as the default.
When you create the role(s) use this property rather than a hardcoded "map to" value this will allow you to easily support environments where the account standards are different by just updating the server property.
When you roll the agents out you could either use the most common account as the standard value or you roll out with a blank users.local and run an external script against the environment to set it appropriately and generate youe import csv file which also sets ADMIN_USER property to the correct value