Category Archives: deployment

SHIPS have set sail, part II

SHIPS as I wrote about in my last post is a system for rotating admin password developed by TrustedSec. It handles both Linux and Windows systems which is great. I read the documentation, I have yet to try it, but I just want to point out a few things that I noticed when reading it.

1. The initial installation of SHIPS is a number of manual steps

This is actually quite necessary as this also builds understanding of how SHIPS works, which is good. The downside of it is that it do take some time to get this up and running. On the other hand, it solves a problem which has bugged sysadmins for years so I can definitely live with it.

2. Dependencies

The required packages of Ruby are easily installed on most Linux distributions, but there is one thing that perhaps is missing a bit and that is the need to have a working PKI (Public Key Infrastructure). The reason for this is that SHIPS uses SSL when communicating between the client and the server, and the client needs to trust the server SSL certificate. Your company or organization should have a CA which can sign the SHIPS server SSL certificate for it to be trusted by your clients. If you dont have this, you will have a harder time setting up the clients. It is possible to work around this by trusting individual self-signed SSL certificates on individual clients, but it is not recommended. There is also an option to use curl (which is used by the Linux clients to communicate with the SHIPS server) with the insecure mode, thereby not validating the SHIPS server SSL cert. Do not use this, instead, if you plan to use SHIPS, make sure you have a PKI to support it to make it work smoother.

3. Idents

Idents are used for managing objects within SHIPS, such as validating which users that can login to SHIPS and retrieve and set passwords as well as managing authorized clients which can connect. Authentication idents can be /etc/shadow, SQLite (database) and finally external using the LDAP protocol for querying users and computers. When it comes to the actual clients, these are handled in arrays unless you using either LDAP or simply allowing any client to connect to SHIPS. If you do allow any client to connect without validating the clients name which is not recommended, it is a possible way to perform a DoS attack against the SHIPS server database. In an enterprise, most would probably go with the LDAP option and most enterprises rely on Active Directory. That does not mean that you are running LDAP. A Windows domain controller does not run LDAP unless you have installed it, it is not included per default when installing Active Directory Domain Services. So, you might have to actually install and configure LDAP in your environment first, and that takes some planning. It is not impossible by any means, but it is additional step that you should be aware of if you are to implement SHIPS using a LDAP as the ident store.

As a last not about idents, it is possible to develop your own ident and integrate it with SHIPS.


LDAP uses port 389 and one should remember that this is a clear text protocol. If you use LDAP as the ident store for managing the SHIPS interface, there is a possibility to sniff data between the SHIPS server and the LDAP server. This might not be a very big problem, but it is possible to use TLS with LDAP over port 636 which would have been better. This is something I would like to see added to SHIPS if it is doable. The authentication between the SHIPS administrators client and the SHIPS server is using SSL so it is protected, but not the LDAP request from SHIPS to the LDAP server.


I think SHIPS is a great solution, quite capable even though perhaps a bit tricky to get it up and running. Sysadmins who expect a simple installer will be disappointed, but as I stated in the beginning, the manual steps adds to ones understanding of how SHIPS really works, and that is very important. I will try to test this once I have everything set up to really support SHIPS, not just getting one with it. SHIPS looks like a quality tool and a great project and I want to test it in the best way I can. I will write about my experience on testing SHIPS later on.

Problems migrating from Windows XP to Windows 7 using MDT 2013 and ADK 8.1

Are you using MDT 2013 with ADK 8.1 to try and migrate Windows XP to Windows 7? Then chances are that you have experienced a problem with the bootsect program or the presence of the bootmgr file.

The bootmgr file in C:\ should not exist on Windows XP, and MDT will try to use it if it exists. MDT creates this file once you try to deploy your MDT task sequence and thats OK, but it should not exist prior to running your MDT task sequence.

Second, the bootsect program used from ADK 8.1 and is located in your deployment share folder under tools\<architecture>\ can produce the wonderful error message on your Windows XP machine, which says it is not a valid Win32 application. Unfortunately, this is true, and Windows XP will therefor be unable to use it to set the boot sector on the machine you wish to deploy to boot using your Windows PE installation in MDT.

The only solution I have found for this error is to the use the bootsect program from the Windows ADK version 8 instead of 8.1. Install the PE environment and Deployment tools from version 8 (on a separate machine from your MDT host) and extract the bootsect programs for both x86 and x64, and replace your 8.1 versions 8(on your MDT host) with the ones from version 8. Do backup the 8.1 bootsect programs first though.

If you simply want to test it, replace the bootsect programs in your deployment share under tools\<architecture>\ and try your task sequence again. The reason for replacing the files in the ADK 8.1 install directory is because MDT will use those bootsect programs every time you update (regenerate) your deployment share. If you have not replaced the files, it will use the 8.1 version and your task sequence will once again fail.

Some mention different using Windows PE versions, but for me it works with version 5 from HP, since I deploy HP machines.

Happy deploying!

MDT Dirty Environment Found

In Microsoft Deployment Toolkit (MDT) you can sometimes experience something called Dirty environment which basically means that something is wrong. This is either because of an unexpected error during your task sequence, most likely a forced reboot which MDT is not prepared for, or there are leftovers from a previous task sequence.

One can of course go through the logs for the machine being deployed, but sometimes it is better to sit in front of the screen of the machine being deployed and see what happens. Personally, I had IE11 as an application being deployed as well as some prerequisites packages which worked well, but caused trouble later on. I noticed that the application step had been running for quite some time and sure enough, when I got to the screen, Dirty environment found. Once I sat down and watched the task sequence I noticed that after IE11 was installed nothing happened, but a few applications later, something caused Windows to reboot. This was not expected by MDT which caused the Dirty environment error. For me, a simple solution was to edit the IE11 application and check the little box to reboot after install. Once that was done, the error disappeared. MDT rebooted after IE11 which in turn configured installed updates (IE11 prerequisites packages) and then simply continued installing the rest of my applications.

As for leftovers, do check out this script by Johan Arwidmark called Final Configuration, it really rocks. You can view his blog post on Deployment Research.