PowerShell is how Windows and Microsoft 365 are actually administered once a business grows past the point where clicking through screens is practical. It is worth understanding at a decision-maker's level, because it determines what your IT support can do quickly and what will take them a week.
What it is
A command language and scripting environment built into Windows, with modules for Microsoft 365, Azure, Exchange, SharePoint, Teams and most Microsoft services.
Anything you can do by clicking in an admin centre, you can usually do in PowerShell. The difference is that you can do it to four hundred accounts at once, the same way every time, and produce a record of what was changed.
It also reaches things the web interfaces do not expose. Microsoft regularly ships settings and reports available only through PowerShell, which is why "the admin centre does not have that option" is often not the end of the conversation.
What businesses actually use it for
Bulk changes
Adding a new mailbox permission to every account in a department. Applying a retention policy across hundreds of sites. Updating job titles after a restructure. Work that is trivial once and impossible three hundred times.
Reporting
Questions the admin centre answers poorly or not at all. Which accounts have no multi-factor authentication? Which mailboxes have forwarding rules to external addresses? Which licences are assigned but unused? Which shared mailboxes have not been opened in a year?
That second question is a security check worth running monthly — external forwarding rules are a common sign of a compromised account, and covered in Microsoft 365 security settings.
Joiners, movers and leavers
Creating an account with the right groups, licences and permissions in one consistent operation. Disabling one properly when somebody leaves — which involves considerably more than turning off the login. See automating user accounts.
Housekeeping
Archiving old files, clearing temporary directories, checking certificate expiry dates, verifying backups completed. Scheduled, unattended, with an alert when something is wrong.
Consistency checks
Comparing the current configuration against what it should be, and reporting differences. This catches the settings that drift when several people have administrative access.
The value is not that PowerShell is faster. It is that it does the same thing every time, and tells you what it did.
The governance a business should expect
Scripts written by whoever is available, stored on their laptop, run occasionally from memory — that is a genuine risk. Not because scripting is dangerous, but because unmanaged administrative tooling is.
What good practice looks like:
Scripts stored centrally, in version control. Not on a personal machine. If your IT support cannot tell you where their scripts live, that is worth asking about.
Reviewed before anything destructive. A script that deletes, disables or reassigns should be read by a second person, and should support a preview mode that reports what it would do before doing it.
Run under appropriate accounts. Least privilege applies here as everywhere. A reporting script does not need permission to delete mailboxes.
Logged. What ran, when, under whose authority, and what changed. This is what makes an administrative action auditable afterwards.
Documented. A comment at the top saying what it does and who to ask. Scripts outlive the people who wrote them.
Credentials handled properly. Never a password in the file. Modern practice uses application identities with limited permissions rather than a stored administrator account.
What it is not for
PowerShell is an administration tool. It is not the right foundation for a business process that people depend on daily.
A script that runs on somebody's computer, requiring them to be logged in, is a fragile way to run a process that matters. Business processes belong in something designed to be a business process — see low-code versus scripting.
Similarly, a script is not a substitute for a properly configured policy. Automating a manual correction every night is worse than fixing the setting that causes the problem.
Questions worth asking your IT support
- Where are the scripts you run against our systems stored?
- Is there a record of administrative changes made by script?
- What runs on a schedule, and what happens if it fails?
- Do any scripts contain stored credentials?
- If you were unavailable, could a colleague pick these up?
These are not hostile questions. Any competent provider will have good answers, and the ones who do not will benefit from being asked.
The commercial case
The return is in three places: time on repetitive administration, errors avoided by doing things consistently, and information you could not otherwise get.
The third is often the most valuable. A monthly report showing unused licences, dormant accounts and unusual mail rules is cheap to produce and regularly pays for itself in one finding.
Our maintenance team automates Microsoft 365 and Windows administration for UK businesses, with scripts held in version control and changes logged. Start a conversation.
