PSEXEC, Computer$ and SYSTEM Access

This recent post on the ConfigManager Team Blog ("How to quickly and easily test your ConfigMgr packages") mentions an EXTREMELY POWERFUL yet often forgotten capability at our disposal:

Using PSEXEC to test SYSTEM account access, both locally and remotely.

I've posted articles numerous times on why I prefer using the SYSTEM account to run scheduled tasks for EVERYTHING, rather than a standard proxy or "service" user account.  Most sysadmins will create a special account, either locally or (more often) in Active Directory, and grant it God-like powers, and use it for running everything from critical services to backup operations, and more.  But when it comes time to manage the password changes, shit gets ugly and scarry.  I don't care if you spend tons of money on utilities to manage that for you, it's a waste of time and money.

Use the SYSTEM account.  For local processing it's the typical way to go anyway.  But for remote jobs it's also the best way to go.  Why?

You don't EVER have to mess with passwords.  So if one of your admins quits, that's one less account you have to worry about being comprised by a password leak.

The account is tied directly to a host computer, so anything performed is done from a known origin (computer), rather than a nebulous user account, which can be invoked from anywhere.  When an event log shows the user entry, it will show COMPUTER$ (where "COMPUTER" is the NetBIOS name of the host computer from which the SYSTEM account was invoked).  It works great for shutting up SOX whiners too.

There's already a group for DOMAIN COMPUTERS, which is never used.  You can create others like BACKUP SERVERS, and BATCH SERVERS, and whatever.

Testing the access of one SYSTEM account against a remote resource used to be tricky and involved things like setting up a one-time AT scheduled task in order to gain access to an interactive CMD session under your own user context (inside the console running as SYSTEM).

psexec -s cmd

This is so easy, yet so powerful.  Once you open the SYSTEM context, you can perform DIR commands to test access to various resources, run installation packages, uninstall products, modify the registry, run WMIC commands, bat/cmd, powershell and vbscript tasks, and so on.