Where Windows has finally caught up is PowerShell. It’s a command line shell, scripting language and all round bad-ass tool. Unlike Linux shells, it’s fully object orientated; whereas BASH and ZSH etc all need to pass strings around, PowerShell uses real objects. This post isn’t really about evangelising PowerShell but if you’re doing any kinds of technical work on Windows, then you should be using PowerShell.

I love customising the environment I work in to make it perfect for me. The annoying thing is that I work on many different computers and it’s a pain keeping all those settings working together. A while back I came across a trick to get VIM settings synced using Dropbox (or a similar cloud file store). I set out to do the same with Powershell.

There’s really three principle things I wanted to do:

1. Ensure all my computers use the same profile
2. Ensure all my computers have access to the same modules
3. Allow computer specific settings to be set easily

PowerShell keeps everything it needs in c:users<login>DocumentsWindowsPowerShell so the first thing I did was copy everything out of there into a folder in Dropbox. I used Settingspowershell.

I now needed a way to connect my actual profile, with the one powershell loads by default. This has to be as simple as possible, since it’s what I’ll need to do on any new computer and I don’t want a dozen line check-list.

Turns out, powershell is happy with a simple dot-source of my profile in the new location. So (since I have different user names at home and work) I calculate the profile location in dropbox and source it. It worked.

I then tested this on another computer and discovered an interesting issue. Dropbox of course downloads files from the ‘net and Windows immediately flags them as being downloaded. PowerShell detects this and won’t run them unless signed. (They’re remote scripts and hence a security risk). I’m therefore lowering the security permissions to allow this. (A better solution might be to remove the download flag on all of them, but there’s a lot of files once modules are included, so this will do for now.)

My profile.ps1 now looks like this:

Next was getting my modules to load. I started by trying to look at way to manipulate the path or to automatically copy the modules to the Powershell folder. This was ridiculously convoluted and there had to be an easier way. It took some searching, but I eventually came across $env:PSModulePath. Yep, the search path for modules.


I therefore mapped a drive to my modules directory and updated the modules path:

My modules all now load without any problems. Note that powershell: is a mapped drive as well.PowerTab was causing some issues, but I fixed those by moving the settings file into the AppData folder; which can be set in the first run wizard. Best solution in any case as different computers will have different things installed, and might need different settings.

That’s all working. The final thing is custom settings per computer. This was actually the easiest, especially once I’d figured out everything for the other two of my requirements and I was able to simply write it:

This looks for a file called profile_<computer>.ps1 and dot-sources it. Simple.

You may wonder about some of my strange variable naming. I tend to like things neat, and I create a whole load of variables during my profile initialisation. I therefore have a naming convention for variables I don’t need once the scripts have finished running, as a side effect of dot-sourcing a script is that the variables don’t drop out of scope.

At the end of my profile therefore I have:

and all my script variables are gone and I’m left with a very neat Powershell session that works the way I want it to, on any computer.