PowerShell Tip #7

For those of us that write PowerShell code every day for ourselves, for our clients and for our work, you would think that the code we write is always natural and always works the first time. Well, yes, that isn’t true. For this tip of the week, I wanted to cover my process for coding and preparing code for whatever the final version happens to be.

• Use a test lab, even if you are working in Office 365

I work with a lot of clients and while some of these clients are now becoming more PowerShell savvy, many are not. Those who are not ask how they can get started learning and doing what I and many others do with PowerShell. First, they need a lab. Yes, you need a lab. Does this mean you need to spend $10,000 to build a good lab? No. Does this mean you need 10 Azure VMs in your Azure tenant? No. So what do you do for a lab?

It depends.

It depends on your goals, what you are managing and what you expect to learn from it. If you need to work with Exchange, then you need Hypervisor (think Hyper-V or VMWare) that can run at least two virtual machines and potentially more. With enough RAM (32 GB?) this can be done possibly on regular workstation hardware. If the needs are greater, then a full server with more RAM, disk and CPU cores may be warranted. Either way, you need a lab you can break.

What about Office 365? Well, you can get test tenants for 30 days. Simply sign up for a trial and have at it for 30 days. If you need to run hybrid, take your workstation from the previous paragraph and parlay that into the configuration. This would allow one to test Azure AD Connect PowerShell, Exchange Online and any of the other workloads from a test lab.

• Use a search engine

Sometimes I have no idea how to code something. Especially when it comes to Exchange Web Services. When I know I need that service, I use my favorite search engine to find some sample building blocks.

Or maybe I have a script that sorta works, but I need to figure out some of the error messages. Solution? Testing and/or search engine research.

Or I have a new project with a task I’ve never done before and I need to figure out the cmdlets – search engine.

Don’t use it as a crutch, but search engines can come in handy when constructing your PowerShell solution.

• Test. Test. Test –> Dev, then QA and then production

Call me old fashioned, but back in the day if you were going to write something and it was going to work the way it was intended a fully developed Dev and QA environment were necessary. Now, that being said, I don’t expect anyone is going to replicate their entire environment to test one script. However, a best effort should be made to recreate a sufficient chunk of an environment to test what a script needs to do.

For example, if you are writing a script to do something in Exchange, then the test environment need at least a copy of your Active Directory (from backup) as well as a copy of your Exchange configuration. Possibly going as far as restoring a copy of Exchange databases to test on semi-live data. Doing so allows you to create a semi-realistic environment to validate scripts on.
Also, when writing and testing your scripts, make sure to test with different scenarios. Common place issues are assuming a script that works for one object will work against a whole slew of similar objects. There is often a disconnect somewhere and that needs to be tested.

So. Test. Test. Test. Then put into production.

• Get help if you’re stuck

It’s handy to know people that can work in PowerShell. Luckily I have my co-workers and access to some great Microsoft MVPs who know PowerShell better than I. So when I get stuck, I Can reach out for some help. If you don’t have friends like that, then use the forums or review trusted blog sites to get you moving along.

• Get real data to test with if at all possible

See Test. Test. Test. Above. Restore a copy of your environmental data to a test environment and use that as a test bed for your script. Make sure the results are correct. I still believe in garbage in results in garbage out. However, what I find in PowerShell is that it isn’t always garbage in or out, but results that fool you into thinking your script is golden…. Then when its run in production it causes an absolute mess. Review your script. Review your results. Maybe even have a second pair of eyes validate that you have the correct solution and you won’t cause additional issues.

In summary, when writing a PowerShell script, put your best effort into it. If it’s for your work, be extra careful that you don’t cause an RGE (Resume Generating Event). So good luck writing PowerShell code. Until next week with our next tip!