Local Admin Account when Installing or Upgrading

So for many moons I have always been told when installing a Solarwinds product (Orion in particular) to not tempt fate and do all the installation and upgrade work under a local admin account on the machine in question. I had one upgrade a few years back that behaved very oddly after the installation, but since I had used my Enterprise Admin account (I was young and didn't understand the dangers involved of using that account for everyday admin) so I felt pretty confident I should have been OK since I was using the God account of the domain. I later found out that an obscure policy setting had caused the installer to have an issue but not outright error out to desktop. Ever since then I have always used a local admin account instead of a domain admin account to do my installs and updates.

That was the recommended practice and I get that that was also when most of us still had fleets of XP machines and were reluctantly upgrading to Windows 7. My peers and those above me have questioned why I think it's still a good idea to follow the Local Admin process saying they have used regular admin accounts for a very long time. Now we have Centralized Upgrade and the technology has changed and improved since Sunburst.

I'm about to use a regular admin account to process and upgrade because that is how they would like me to handle the task. But I put the question out to all of you... am I just being overly cautious? Am I rooted too much in the experiences of the past, that I'm not willing to leave the "tried and true" method back with those XP and Win7 machines? I'd like to hear your thoughts and perspectives. Thanks!

Find more posts tagged with

orion installer

npm upgrade

update

upgrade

Accepted answers

All comments

jm_sysadmin

Admin rights to the server are the same no matter how you get them. If is a local account in the admin group or a domain user, or the Domain Administrator, they act the same. However, policies both local and from the domain's GPO's can impact your ability to install and configure software. By default, nothing should interfere, but it's hard to say that nothing in your environment will be an issue.

apatheticallyalert

Correct. As I mentioned above it wasn't the Admin account that caused my problem, it was the domain policy that came as a result of using a domain account that proved to be the culprit. Therefore, I had been told even from Support back in the day that just use a local admin account to avoid any issues with the domain GPOs.

monitoringlife

Agreed. Making the SOP to 'use a local admin' is to reduce support ticket load.

Most of my clients don't allow the practice, and I would not be able to login without and auditable account unique to me.

apatheticallyalert

Perhaps I didn't clarify this point. Yes I used the Enterprise Admin account back in the day. The local admin account that I have used in my work since those early days has been a specfically created account by me with group membership in the local admins group on the machine. It was not the default Administrator account for the machine. For auditing purposes it was unique to me and to the task being performed. When finished upgrading, the account was disabled until I needed it again.

monitoringlife

Every shop has their own unique security and compliance needs. As long as your leadership are happy and your upgrades are working, whatever gets the job done is fine in my book. Using a local admin does rule out any account GPO issues.