Tag Archives: powershell

Disabling SMB1 after WannaCry? Make Sure SMB2 is enabled

Published / by Rens Hollanders / Leave a Comment

After recent events in the online world, everybody is in a frenzy patching their servers, disabling SMB1, removing the feature from Windows 10 and Windows Server 2012 R2 (after It should have been done way way before). So was I. This week’s priority at the customer I’m working for is entirely dedicated to patching servers (if they weren’t patched prior to WannaCry, which was a small percentage nevertheless) and disabling and removing the SMB1 feature on all the machines.

A lot has been written about WannaCry and how to deal with it. The two most helpfull articles come from big MS itself: How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server and WannaCrypt attacks: guidance for Azure customers.

After patching and removing the feature (directly instead of just disabling it first) on a Windows 2012R2 Server, I discovered I couldn’t browse to the server any longer. Each time I did a: “\\sctxps-01\d$” (which is a Citrix Provisioning Services Server) I got a message the server couldn’t be reached:

After hitting some key phrases on Google and finding the recommendations of Microsoft, it struck me. The Set-Command: “Set-SmbServerConfiguration -EnableSMB1Protocol $false” which configures SMB to be turned off, can also be partially used as a Get-Command to see it’s current states. And look what we found:

It appeared SMB1 Protocol was still turned on, however due to the removal of the feature entirely from the Server, the machine wasn’t reachable any longer through UNC, IP and even localhost. After hitting the command: “Set-SmbServerConfiguration -EnableSMB2Protocol $true” the server could be reached again.

It appeared someone had configured SMB1 before and turned of SMB2. Due to the removal now the servers SMB shares couldn’t be approached any longer over the network.

So please check your SMB status with: Get-SMBServerConfiguration before doing something drastic like removing SMB features. Of-course in an ideal world this would all be planned, risk, impact and analysis etc. But in an ideal world their wouldn’t be any Cryptolockers either.

Cheers! Rens

 

MDT – Updated Powershell scripts for Windows ADK 10 and MDT 2013 update 1 Build 8298

Published / by Rens Hollanders / 3 Comments on MDT – Updated Powershell scripts for Windows ADK 10 and MDT 2013 update 1 Build 8298

Hi there,

So the word is out, Microsoft has re-released MDT 2013 update 1 after several bugs and errors have come forward during the deployment of Windows 10.

Each new version means that if you use scripts which have a dependency with tools such as MDT, you’ll need to check it for compatibility.

Since two years now I rely on configuring an entire deployment share environment by powershell. Since clicking and mouse pointing my way through ADK and MDT setups were killing my brain cells one setup at a time.

I’ll save you the deep dive into the script’s but here’s a short explanation:

Script 1 will: Automatically download Windows ADK for Windows 10, and MDT 2013 update 1 Build 8298 to the folder from where the script is executed and create a “Software” folder where the content’s are stored.

Once the downloads are completed both tools are installed with default settings silently. And lastly the script will enable the .NET framework and WDS feature / role to configure the server as a MDT deployment server.

Script 2 will: First ask you if you want to split wim files prior to configuring the deployment share. I’ve incorporated this question, since 4 Gb is the FAT32 file size limit and this is a need little option to instantly make your FAT32 UEFI deployments work! Next it will automatically configure an entirely new deployment share in a matter of seconds, with a logical folder structure. Selection profiles, the configuration of WinPE settings and the overall Settings.xml, read more about it here: MDT2013 – Configure everything with Powershell!!!

Now how does this look?

figure 1.1: Software folder created by download and installation scriptMDTDownload002
figure 1.2: The download and installation script doing it’s magic MDTDownload003
figure 1.3: Behold the installation of ADK, MDT and WDSMDTDownload004
figure 2.1: Execution of the Configure DeploymentShare scriptMDTConfigure001
figure 2.2: Script in progress..MDTConfigure002
figure 2.3: Script completeMDTConfigure003

figure 2.4: MDT Environment configured completelyMDTConfigure004

You can find the script’s here:

MDT Download and Install v1.0: OneDrive

MDT Configure DeploymentShare v3.0 for MDT 2013 Update 1 Build 8298: OneDrive

Questions, improvements, or want to show your appreciation, just give me a shout out in the comments

Cheers! Rens

 

MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Published / by Rens Hollanders / 8 Comments on MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Hi, just a quick post about an idea I wanted to share with you all:

A request from a colleague -since we are using MDT to deploy our corporate machines- was to create a mechanism that prevents the re-partitioning and formatting of hard drives that have already been deployed with MDT.

Now this can easily be done by creating the following steps in your deployment task sequence:

figure 1.1: Set Task Sequence Variable – DeploymentType

005

As you can see above, the Task Sequence Variable “DeploymentType” will be set, during the execution of the task sequence. But how can we achieve this only happens if for example the machine has already been installed with MDT a previous time?

figure 1.2: Task Sequence Variable Condition

006

By setting a condition on this Task Sequence Variable. For example by checking if a certain file exists. Naturally it is key, that this file will be created at the first initial deployment of the machine, or the file is created manually afterwards. The reason why I check both C: and D: drive, is that within Windows PE, it may occur that sometimes your C: drive is detected as D: drive due to the “System Reserved” or “System” partition.

This way I’m always right.

Now, to generate a file for identification, I’ve created a powershell script, which dumps certain Task Sequence Variables queried by the ZTIGather.wsf script in a text file, together with a couple of WMI queries:

The script is pretty straight forward:

First it sets the invocation path, which is the path from where the script is called. Then it sets the variables which are needed as input for the script. And the cool thing is, since ZTIGather.wsf queries the entire machine, we can use the MDT Task Sequence Variables as input for our script, which will be dumped into the text file.

To determine the computername, I wanted to use the OSDComputerName task sequence variable, but strangely enough, it outputted the AssetTag instead, for this reason I used the WMI query:

And the same thing goes for the Windows Operating Sytem version:

And bitlocker recovery key:

I then just needed to format these results in a readable usable manner, to get all my variables straight.

Now that’s out of the way, I needed a folder to store this information in, but I don’t want to bother end-users looking into it. So I create a folder called “MDTRollout” and placed it in the root of C:\ and give it the “Hidden” attribute, also I perform a check if the folder itself does not exist, in that case it will be created.

The same thing goes for the text file which is automatically created, if it does not exist. And if the file exists, it will add the content, for example when the machine is reïnstalled for the 2nd, 3rd, or 50th time.

And now to show you the result:

figure 1.3: No folder present at first

001

figure 1.4: running the script

002

figure 1.5: Task Sequence has finished

003

figure 1.7: Contents of the DeploymentInfo.txt004

There you have it, a little usefull file which can be used to quickly evaluate the computer’s identity and configuration. Which on it’s turn, forms the basis to perform a MDT REFRESH scenario, instead of a NEWCOMPUTER scenario.

The script can be placed in the .\DeploymentShare\Scripts folder, and executed with a “Run Powershell Script” step from within the Task Sequence properties pane. You can call the script as following: “%Scriptroot%\MDT_DeploymentInfo.ps1”, the great thing about doing it this way, is that MDT handles the execution policy of powershell which would otherwise prevent the execution of the script. Normally it is necessary to set the policy to “Bypass” or “Unrestricted”.

figure 1.8: Calling the script

008

figure 1.9: Testing it yourself

007

Now to test the script yourself, a custom task sequence with the following two steps should do the trick:

  1. “Gather”
  2. “Run PowerShell Script”

Hope this can be of use to anyone else.

Find attached the screenshots used, and the actual script, which can be downloaded

zip
MDTDeploymentInfo.zip

Cheers and have great 2014/2015! Merry Christmas and a Happy New Year!!!!

 

MDT – Versioning made easy (powershell = king)

Published / by Rens Hollanders / Leave a Comment

The great thing I like about doing projects with customers, is that each and every customer has it’s own challenges. And I think it is safe to say, that challenges brings out the best of all of us IT Pro’s.

In this particular post, I want to talk about the Microsoft Deployment Toolkit, versioning mechanism: ..MDT has no versioning mechanism 🙁

Wouldn’t it be nice to just have an option to duplicate a task sequence, like MDT’s big brother Microsoft System Center Configuration Manager?

Well that day has come my friends 🙂

Currently I’m working on reverse engineering a Citrix XenApp 6.5 environment which needs to be rebuild from the ground up with MDT. And after it has been built, it needs to be managed, improved, extended further when necessary.

Now it is perfectly possible to duplicate task sequences manually. Just create a new task sequence with the wizard within MDT, and copy the ts.xml and optionally the unattend.xml from your control\<tsid> folder to the new control\<newtsid> folder, and voilá your task sequence is duplicated. But wouldn’t it be nice to do this automatically?

Depending on the tools that are present in any particular organization, since MDT is free, and tools such as RES Automation Manager and System Center Config. Mgr. cost money (..and particularly Config. Mgr. costs lots of it too) I wanted to create a solution for having some kind of versioning system in MDT.

Since I’m getting more and more familiarized with PowerShell, I can kick in the open door by saying what we all know: PowerShell is truly King. Although I do not poses all the knowledge, luckily I have multiple colleagues who are willing to help me at any given time. This time I would like to thank Pascal Zeptner, for spending his free time with me 😀

Now before we are going to talk about the script, it is imperative that your Task Sequence ID is built up out of the following naming convention:

  • OSB001
  • OSD002

I maintain this convention at all of my MDT implementations. The abbreviation OSB stands for “Operating System Build“, while OSD stands for “Operating System Deployment“. The essential difference between the two is, that the first one is used for creating reference images for target machines. While the second is used for deploying the reference image that is created, to target machines.

And to have a complete MDT environment with an orderly created folder structure in less then 20 seconds, please visit this blog: MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Behold the script:

Function

First of all, the script checks for elevation, if you do not run this script elevated it will not execute:

Secondly, the script needs certain variables made clear to work with. In this case the following static variables:

After these variables are filled in. The script will import the MDT PowerShell module, located at the default location where MDT normally is installed. If you have installed MDT elsewhere, you will receive notice that the MDT module was not found and the script will terminate.

Next, a new PowerShell drive will be created, so we can browse the MDT virtual folder structure:

After this, the real stuff begins: In the following lines of code, the properties of a task sequence will be queried. This happens with the “Out-Gridview” cmdlet, since this presents a nice selection dialog, to select the desired task sequence which we want to duplicate.

From this selected task sequence, we query it’s ID, and increase the number on the ID with +1 to create the new Task Sequence ID.

The same thing goes for the Task Sequence Version, which is also queried, and increased with +1. As soon as the version of the task sequence hits .9, it will increase the master version from 1.0 to 2.0.

Lastly the name of the task sequence is queried, and assuming we use a specific naming convention for our task sequences, which uses “v1.0” at the end. The last three characters are removed and replaced with the $NewTSVersion variable. This causes our newly created task sequence, to receive a name with the increased version number too!

Now all the information we need to know to duplicate our task sequence is known, we can actually create a new task sequence and copy the contents from our reference task sequence to the new task sequence:

As you can see, there are some checks built-in that verify if the new to be created task sequence does not already exist on physical folder level.

Now to underline all this, screenshots:

figure 1.1: Select designated task sequence for duplication

versioning001

figure 1.2: Task Sequence duplicated

versioning002

figure 1.3: Press F5 to refresh and see the new task sequence

versioning003

figure 1.4: Perform duplication at v .9

versioning004

figure 1.5: Version 2.0 created

versioning005

figure 1.6: Press F5 to refresh and see the new task sequences

versioning006

figure 1.7: *.xml files are copied from destination task sequence to new task sequence

versioning007

..and that my padawan automaters, is how the cookie crumbles.

Comments, questions, improvements? Please let me know in the comment section. It’s as always much appreciated.

The script and images used in this blog can be downloaded here:

zip
MDTVersioning.zip.zip

Cheers! -Rens

 

MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Published / by Rens Hollanders / 5 Comments on MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Very recently, deploymentreseach’ Johan Arwidmark, blogged about configuring your DeploymentShare properties (which are saved in .\Control\Settings.xml) with Powershell.

Some time ago I started working on some Powershell scripts myself, mostly oriented on configuring the bootstrap.ini and customsettings.ini, and creating some folders within the MDT Workbench.

While I never had gotten the time and energy to finish it, Johan’s blog basically pushed me over the edge, and then it happened… I went BESERK /cannot compute 😛

beserk

The result you can find in the following script which not only configures your deployment share properties, but also configures:

  • Bootstrap.ini
  • CustomSettings.ini
  • Modifies “.\Scripts\Litetouch.wsf” to use the _SMSTSPackageName variable
  • Configure DeploymentShare Properties
  • Creates a folderstructure within MDT
  • Creates selection profiles within MDT

The script! Updated @ 2014-03-20

Basically this script can be divided into five pieces:

1. Constants

The constants that I have declared are the variables that represent the value that is shown, by modifying these values, you can customize and personalize this script for your own purposes. This script is primarily intended for new to be configured deployment environments, so keep in mind that using this script on existing environments will overwrite all content within the bootstrap.ini and customsettings.ini!

2. Configuring Bootstrap.ini and Customsettings.ini

Basically I use a multiline string for both my Bootstrap.ini and CustomSettings.ini and within that line of code, on certain places I call my variables. This way the variables will be used for input, instead of having to change a server name every single time on every single row of code.

3. Configuring the DeploymentShare properties

This part we already know from Johan / deploymentreseach, however I’ve took the liberty to customize it to my wishes, and fully write out all the available settings in .\Control\Settings.xml

4. Configure a logical folderstructure within the MDT Workbench

This part is quite new, I now know again thanks to Johan and Roger the Young a PSDrive can be browsed from a powershell command prompt, just type: dir ds001: and you can actually see and browse the MDT Workbench ‘folder structure’.

figure 1.1: Browse PSdrive

psdrive

If you want to browse any further, just type dir DS001:\Applications or “DS001:\Operating Systems” (note that if you use spaces in your folders, you need to use quotes “”)

5. Configure selection profiles for Driver and Packages selection

The last thing I wanted to do is configure pre-configured selection profiles which can be uses for injecting certain drivers, targeting packages, creating media etc.

What has changed since 2014-03-20

The script needed some simplification to avoid having to enter the same values at different places. Also now the script creates an entire deployment share for you. So now there is no need to create an deploymentshare with MDT before executing this script. Lastly the ZTIDiskpart.wsf will be modified to calculate with binary metrics. So a 100 Gb disk partition specified will actually end up as an 100 Gb disk partition instead of 98,7 Gb.

Closing

Is this the right way to do it, I have no clue, what I do know is that I never want to configure a deploymentshare manually ever again, so this script definitely helps me. Also, adjusting the values of the constants declared is a fraction of the effort I have to put in vs. going through “Create folder” wizards for the 50th time.

Special thanks go out to scripting wizard Roger the Young a.k.a. “DrillSergeant” and Johan Arwidmark, for giving me renewed inspiration to continue to develop this script in what it has become.

ps I. forgive my powershell language, using words as constants, variables, properties and values, are perhaps not used in the correct way! -im still trying 🙂

ps II. also I can imagine this script can be simplified drastically, and I don’t mind if you do, as long as you share it back with me, like I shared it here with you 😀 Or as the Germans say: “wiedersehen macht freude”

Finally, you can download the script here:

zip
ConfigureDeploymentShare.zip