Automagically update your MDT Boot Image

In case you’re using Microsoft’s awesome Microsoft Deployment Toolkit [MDT] solution, there might be a thing you don’t often do, but can take up  a while of your time and can have quite some impact if you forget a few steps..

What I’m talking about is updating/regenerating your MDT Boot Images and replacing them within Windows Deployment Services [WDS].

Of course such a thing is ideally done through PowerShell as it automates and thus limits the amount of human errors possible.

Profile

An important thing in the script is currently ‘missing’ as it’s currently placed within my $profile on my MDT server, so I’ll also provide you this, as it’s important for actual usage:

It’s rather simple, but required in order to gain access to any of the MDT related PowerShell cmdlets.

Since I’ll use it for more than just this script, I’ve placed it within my profile.

The solution

Now it’s not ideal and I’m sure June Blender will have a word with me on my [currently] lacking help notes, I thought I’d share it anyways 😉

I’ll delve more into techniques used in the script in another post, but there’s a new trick or 2 that I’ve not yet discussed on my blog before which might be interesting to browse through.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

You’ve got the Power!! plan….

Today I was playing around on some machines on which I noticed the Power Plans were set incorrect, Balanced on a server :'(

Now of course I can do this manually, or I can use PowerShell instead!

Tools not scripts

Since I want to use this more often and want to create my own “toolbelt” [aka module with common tools], I’ve decided to make the solution as advanced functions, not just scripts.

This means that if you simply copy/paste them, you will need to dot source them first in order to use them.
Dutch PowerShell MVP Jeff Wouters has a good article on this in case you want some more info on this.

Quick info:

to the directory in which you have the .ps1 files in case you have them saved seperately and dot source them using

The following functions are provided:

  • Get-AllPowerPlan
  • Get-ActivePowerPlan
  • Set-ActivePowerPlan

I’m guessing the names sort speak for themselves, but do take into account that the Set-ActivePowerPlan relies on the other functions to… well… function 🙂

The Code

 

Happy Scripting! 🙂

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Invoke-Command wrapper function

A quick post this time about something that might be helpful for others, something that saves me from typing too much 🙂

I’ve noticed over the last week that I’ve been doing various remoting commands through Invoke-Command to the same machines, which require additional credentials to access.

Why re-type something when you can automate it 🙂

Before

I used to have to do the following:

Where my SCCM servers are in another forest as my management machine and $CredStore is my personal Credential folder which contains credentials for various systems/domains, as I use these regularly and I’m lazy

After

After some tinkering around and a great tip found on Thomas Maurer’s site, I’ve narrowed it down to:

I’ve personally decided to keep the 2 variables in my $profile as I tend to use those for other functions as well, but otherwise I would recommend placing these in the begin {} block.

The magic here is the converting of a string to an actual scriptblock by the PowerShell engine, accomplished by the following piece of code:

The Code

 

Happy Scripting! 🙂

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail