Bulk password change with Powershell

Every 3 months or so I am required to change a bunch of users passwords in accordance with our security policies.  In the past, this has been a tiresome task, but over the last 6 months or so I have been improving on my Powershell skills.  Knowing that this would be achievable through a PS1 script, I set about looking through the Internet to find the solution, however I came up blank.

Through trial and error I managed to get the following working.  The csv file has two columns; name,password.  Once you have connected to a DC, authenticated with a domain admin account and imported the AD module, run this line:

import-csv C:\temp\Users.csv | foreach { set-adaccountpassword -identity $_.name -reset -newpassword (convertto-securestring -asplaintext $_.password -force)}

Works a treat!  Thought I’d share since I was unable to find anything similar on the Interwebs…

Advertisements

A Summer vacation…

…Albeit an extended one!

I’m back again after taking a bit of a break through the summer months, I can say ‘Summer months’ ’cause we actually had a Summer this year in Scotland!

It’s been a fairly busy year for me as I have moved home and started a new job.  Gone are the restraints of working within the Higher Education sector!  It’s great to be working for a company willing to spend money on new tech and I am relishing the opportunity to take full advantage of it!

Over the coming months I’ll try to post up what I can about ongoing and completed projects.  In the pipeline is a move from our current backup solution, Backup Exec 2010, to Backup Exec 2012.  I’ll no doubt post some topics relating to that in the first quarter of the new year. 

I’m also experimenting with Powershell 3.0 after watching some great videos on the Microsoft Virtual Academy website, a great pool of FREE video training made by MVPs.  So much fun to be had!

Thanks for stopping by, please feel free to comment and I’ll try to respond when I come up for air!

 

Doug

Oracle VMs

Of late I have been involved in many projects.  The largest of which is the full virtualisation of our current Oracle provision.  The project challenges were to create a virtual image that was powerful enough to run various Oracle services, to not void any license agreements if students were to take the image home to work on.

I’ve spent quite a bit of time this last year playing around with various virtual environments and was quite eager to put some of this new knowledge to the test.  The problem with oracle is that it is very resource hungry so running it in a virtual environment on top of a host OS isn’t very viable.  The solution for this was to create a VHD that could be added to the native boot menu and booted to as if the machine was a dual boot.  Doing this unlocks the full power of the machine to the Virtual Image, but retains the flexibility of a being a Virtual Hard Drive and therefore a file!

So far we are 6 months in to teaching using this new method and everything seems to be running smoothly.  It’s not the ideal solution, but the trick is to provide the best service you can within the physical and financial constraints of Higher Education!

Time permitting, I will get a quick guide to providing this infrastructure along with things to look out for in the coming weeks.

Installing a 32 bit OS on an EFI system using MDT 2012

A couple of months ago I blogged the method I am using to deploy VHD images side by side with a host OS via MDT 2012.  I have been fighting a battle with EFI based systems, namely HP 8200 Elite SFF, and thought I’d share my findings if for nothing other than my own future reference.

The deployment of my 32 bit VHD has been running fine on every other machine we have.  When it came time to test it in the lab that it will mainly be used in, I ran into some troubles.  After some digging around, I discovered that  32 bit Operating Systems cannot be installed on a GPT partitioned disk.  I noticed from within the Disk Management console, that every HP 8200 Elite that had been built using MDT had a GPT partition type, despite the TS explicitly selecting MBR.  This is because MDT 2012 is ‘smart enough’ to detect EFI systems and will automatically ignore any settings in the Format & Partition stage, and partition the disk as GPT.

This was very irratating.  I had a 64 bit host OS and a VHD that HAD to be 32 bit.  I could copy the VHD across without problem.  I could even add it to the BCDStore OK, but when I tried to boot from it, it would launch Windows RE.  This is due to the relocation of the BCDStore under EFI systems. It is no longer contained in the 100MB System Partition, but on NVRAM on the MotherBoard.

To try and over come this issue I tried several approaches.  Firstly I disable the Format step in the TS and edited the Unattend.xml, instructing it to format and partition the disk at this stage.  That failed as by the time the Unattend.xml file has been called, the TS has already begun saving things to the local disk, thus formatting the disk would break the deployment.

Next I wrote a diskpart script to format the disk, create the system reserved and the Windows partition, but this would lead me to more errors.

Finally, I decided to have one last search through the BIOS menu to find some hint of EFI that I could disable.  The only place where EFI is mentioned in the BIOS is within the Boot Order selection sub menu.  From this menu, I disabled EFI devices as boot options.  From within the TS, I re-enabled the Format and Partition step and tried to run the deployment again.  This time, with more success.

In the end, a fairly simple fix.  It’s funny how sometimes you can get carried away with elaborate patches and scripts upon scripts, when actually the fix is a simple one step process.  My finishing thought:  Having trouble installing a 32 bit OS via MDT 2012 to an EFI system, namely HP 8200 Elite?  Disable EFI devices from the boot menu!

Mac GUI Bootloader using rEFIt

As eluded to in a previous post, I used rEFIt to manage the GUI bootloader of our iMacs.  This simplifies the boot menu when dual booting an imac.

Working with rEFIt

rEFIt creates a GUI bootloader for Macs.  It is very easy to work with.  Simply install it and navigate to the /efi/refit folder and open refit.conf using the Texteditor.  The .conf is very well laid out and describes in sufficient detail which parts control what aspect of the GUI.

I have created a .bmp logo which I have dumped in the refit directory, referenced it in the .conf file and uncommented the line from the script.

For obvious safety reasons, I have uncommented the ‘disable all’ line from the .conf file so that the only options for booting the Mac is the internal disk.  By default all methods are displayed in the GUI meaning that users can boot from external USB, CD and from the network.  You can, if you prefer, select which of these items you’d like to disable if you prefer not to disable all of them.

You can select which partition or what Operating System takes priority in booting up.  Like the other options, the commented lines within the .conf give details instructions on this, but basically W=Windows, L=Linux, and so on.

Using Iceberg to redistribute Mac software

A continuation on the previous post of how to automate the Lion deploy process…

As with the last post, check the foot of the post for references.

Working with Iceberg Package Manager

Some software that we use can only be installed from the App center without the option to download first.  This makes it difficult to obtain an installer to roll out to client machines.  Luckily, with the help of Iceberg, this isn’t an issue.

Iceberg is able to lift most installed packages right out of the Applications directory and package them into a .pkg ready for redistribution.  Some packages aren’t as simple as that and we will get in to those later in the section.  For now let’s focus on the simple…

Download and install Iceberg, which you can grab from here:

http://www.macupdate.com/app/mac/14516/iceberg

Launch Iceberg and from the toolbar along the top of the screen, select File>New project.  For a basic package, like our example of Texteditor, we can stick with the core template package.  Name the package appropriately and continue to the next screen.

Iceberg New Project Wizard

In the new window, expand the name of the package from the left hand pane and select Files.  In the central pane, right click Applications and select Add Files…

Add files to the Project

Navigate to the location of the installed application and double click it.  Press OK to the popup about absolute paths, if applicable.  You should know see the application under the Applications header.

Adding files to the project

Next, click on the Settings tab from the left hand pane.  Here you can amend the details of the package to reflect that of your own business.

Change the default name to something appropriate to you

From the toolbar along the top of the screen, select Build and Build again.  Close the window when it is complete.  By default Iceberg saves the built pkg to the current users home area.  The directory is named after the package itself.  The .pkg will be in the sub directory named Build.

As I mentioned earlier, this method works for the majority of applications, but not all of them.  Some applications that I found NOT to work this way were Xcode, Office 2011 and McAfee 1.1.

If you skip down to the references at the bottom of this document, you will get a good example from another blogger detailing the process to repackage Office 2011.  I found that this was didn’t work very well with Xcode 4.3.2 so had to go about that another way.  Also McAfee I couldn’t repackage at all using Iceberg as the main .mpkg calls upon a further four .pkgs all with their own post and preflight scripts.

Deploying McAfee

The McAfee .mpkg invokes four smaller .pkg’s making it quite difficult to automate.  The way I found to get past this was to copy the installer to the client machine using the file copy task in DS.  Then to a script that runs at the end of the workflow, I added the following line:

Sudo installer –pkg /users/administrator/desktop/mcafee.mpkg –target /

It’s not the cleanest method, but it works.  I then have a cleanup script that runs after this one which deletes the .mpkg.

Deploying Xcode 4.3.2

This was the most challenging package I faced when configuring the deployment.  Like McAfee, the .mpkg for Xcode invokes another .pkg, Mobile Device Framework.  The only way I was able to get around this was to split this up into two packages.  Package one installs the Mobile Device Framework, and the second installs Xcode.

Before we can look at any of this, we will need the download.  To get this, you need to create a free developers account and login to the following site:

https://developer.apple.com/downloads/index.action 

Once the installer has finished downloading, mount the .dmg.  Right click on Xcode and select Show Package Contents and navigate to Xcode>Contents>Resources>Packages and copy MobileDevice.pkg to the desktop for easy access.

Launch Iceberg, and like before create a new project.  This time, we will be creating a Darwin Package so select the appropriate package type from the menu and name the project.  Before completing the package, I usually copy the MobileDevice.pkg to the newly created project folder.  This keeps everything together should I need it again at a later date.

From the project window, expand the package by clicking the down arrow on the item in the left hand pane.  From the list, click on Scripts.  Simply drag and drop the MobileDevice.pkg into the bottom window and ensure the checkbox to the left of it is ticked.

Adding the Mobile Device Framework to the Project

The next thing we need to do is create a postflight script and link it to the Installation Scripts window as shown in the above screenshot.  The script takes the form of:

#!/bin/sh

 

Sudo installer –pkg “$1/Contents/Resources/MobileDevice.pkg” –target /

Once you have written the script, name it postflight and verify that it doesn’t have an extension of any kind, then make it an executable by running the following command in the terminal:

Sudo chmod a+x /path/to/postflight

Copy the newly created script to the project directory, for the same reasons that we copied the MobileDevice.pkg there earlier.  Now drag and drop to the postflight area of the Installation scripts of the project window, ensuring that the checkbox to the left of postflight is ticked.

Once you have done this, build the project and leave it to one side.  Now we need to create the package for Xcode itself.  To do this we need to install Xcode on a test machine and be sure to install any extras like iOS simulators from Xcode>Preferences>Downloads.

When you are happy with the Xcode installation, we need to run a small command from the terminal to ensure permissions are correctly set before we can capture it:

Sudo chown –R root:wheel /Applications/Xcode.app

Launch iceberg and create a new project, same as last time – a Darwin package.  Expand the package so that you can see the Files tab.  Under Applications, rightclick and select Add Files.  Within the new window that pops up select Applications and choose Xcode.  That’s all there is to it!  Build the project and move both project directories to your deployment server’s Packages repository.

As mentioned earlier, I took a lot of influence from Mr derflounder’s blog when trying to package Office 2011 and Xcode 4.3.2.  I highly recommend a thorough read of his comments before undertaking these deployments.  You can find links to his blog at the bottom of this post.

 

References

Download the installer for Xcode from the developers site here:

https://developer.apple.com/downloads/index.action

Iceberg User guide:

http://s.sudre.free.fr/Software/documentation/Iceberg/English.lproj/documentation/index.html

 

I had a lot of ideas and help from this insightful blog.  Here is a link to one of his posts, which helped me repackage Office 2011:

http://derflounder.wordpress.com/2011/06/24/re-packaging-metapackages-with-iceberg/

Another useful post from derflounder:

http://derflounder.wordpress.com/2012/02/17/building-a-grand-unified-xcode-4-3-installer/

 

 

 

Deploying Lion & Windows 7 to iMacs

Well I’ve been pretty busy lately working with Mac’s which is something I don’t do very often.  We have finally gotten round to automating the rollout of our Mac lab.  I used a combination of tools as we dual booted the iMacs with Lion and Windows 7.  To deploy the Mac side of things, I used DeployStudio.  I used rEFIt to manage a GUI bootloader to switch between Lion and Win 7.  To rollout Win 7, I used an altered Task Sequence from MDT 2012.  Here is how I managed to get it all working…

Please see the foot of this post for references…

The theory

Deploystudio is a fairly straightforward package.  Firstly, you create your deploy server via the DS assistant.  Then create a netboot image – this is basically the mac version of a WinPE though a lot larger in size, nearly 2.5 GB!  The netboot image is a striped down version of the Mac OS and is what we boot into when running a workflow.  As well as giving us access to the features of DS, we can also access tools found in Utilities; disk and network utilities, terminal, etc.

From the DS admin tool, we can amend our workflows and create new ones.  We can add packages for deployment and we can monitor the ongoing deployment tasks to clients.

When it comes to automating the installation of applications we can use the Iceberg package manager running on a target machine, to capture the apps and then copy them to the deployment server.  Some packages require more work than others, hence in our main deployment workflow we have multiple package installation bundles as some software is happy to be installed from the netboot image, others require to be installed at next boot.

As we are dual booting the iMacs, we will be using rEFIt to manage a GUI boot loader, giving the user a graphical interface in which to select whether the mac boot into Lion or Windows 7.

Our master workflow will partition the drive in a way, which will allow us to install Windows 7 after the successful installation of Lion.

The Deployment process

Once we have the server setup we can turn our attention to the deploy admin utility and begin the deployment process.  The deployment process itself couldn’t be simpler.  Much the same as MDT 2012, we will boot to the netboot image and select the workflow we want to run.  Once we click the play button, the workflow does its thing and requires as much interaction from the user as defined in the workflow configuration.

Before delving into that, we’ll have a look at how to create a Deployment server.  The instructions for setting up and configuring the server have been influenced by the instructions within the DeployStudio manual, which is referenced at the end of this document.

Configuring the server pre DeployStudio

DeployStudio should be installed on a server platform; any form of Leopard or Lion will suffice.  We will be making some changes to the services running on the server.  To do so, open Server Admin.

DeployStudio, DS, doesn’t work well across subnets so you need to ensure that the server you are installing to is on the same subnet as the machines you will be deploying to.  You need to ensure you have a static IP and if the server itself does not have DNS running, then it should have knowledge of the appropriate DNS server.

Only AFP and Netboot services need to be configured, OpenDirectory can also be configured but is not a requirement.

AFP, Apple File Protocol, allows us to share images scripts and files across the network.  All we need to do with this service is ensure that Guest access is set to default and then start the service.

We cannot configure the Netboot service until we have created a netboot image, but we will discuss what has to be configured here.  With Netboot selected in the left hand pane, select Settings>General.  Check Ethernet, ensuring that you select the correct Ethernet port if you have multiple Network ports on your server.

Netboot Settings from Server Admin

Netboot Settings from Server Admin

From the bottom of the main window, check off the image and data locations.  Ensure that you SAVE NOW, as you won’t be able to complete the following step if you haven’t done so.

From the tab along the top of the main window, select images.  Verify that the netboot image that you created using the DeployStudio Assistant is visible.  Select it, save and start the service.

From Workgroup Manager, create a deployment admin account.  This is the account that will be used to login to the netboot image and run the workflows.  It is important to ensure the password is very secure as with any admin account.

Back on the Server admin, we need to ensure that the admin account just created has correct permissions to the Public directory as this is where the DeployStudio repositories will be stored.  To do this, select the server from the left hand pane and choose File Sharing from the top of the main window.  Select share points and then select Public.  Under the Permissions section of the window, use the + button to add the newly created deployment admin account to the permissions manager.  Ensure that the admin has Read & Write permissions, save and exit.

Setting the permissions for the Deploy Admin account

Setting the permissions for the Deploy Admin account

With public still selected, click browse and then New Folder and call it DeployStudio.

Installing and configuring DeployStudio

Download Deploystudio from here: http://www.deploystudio.com/Home.html.  Once you have it downloaded, go ahead and install it.

Once installed, open DeployStudio Assistant which can be found in /Applications/Utilities.  From the list of options, select Setup a DeployStudio server.

DeployStudio Assistant

In the next window enter the server address followed by the port number, which will look something like this:

https://ServerName.com:60443  <– Default port number.

The username and password will be the account that we created in the last stage, the deployment admin user.

In the next window select whether this server will be a master or a replicator.  Select the appropriate option and move onto the next screen.

This window is for the repository settings.  Ensure that you select Network Sharepoint so that the repository is accessible throughout the network.  Continue to the next screen.

Create the path to the repository, which if you followed the instructions when configuring the file sharing settings for the server, will be under Public.  The syntax for this field will look similar to this:

Afp://ServerName.com/Public

Enter the username and password for the deployment admin account and continue on to the next screen.

Unless you require email notification, you can skip past this screen.

The network security window; ensure that com.deploystudio.server is highlighted from the drop down menu.  Select the appropriate interface for your setup and leave the port number as the default 60443.  Verify that the Reject Unkown computers box is UNCHECKED.  Continue to the next screen.

This is the user group window.  If you require more stringent security settings, you can only allow access to specific user groups.  These groups must be created in the Workgroup manager although users can be added to the groups at any time.  Continue to next screen.

This screen allows you to enable or disable Multicast.  Even if your network is incapable of working with multicast, it is not advised to disable it at this point as you will not be able to change it at a later date.  It’s best practice to leave this enabled.  Continue to update the server settings and hit OK when the process is complete.  The server has been configured, next up is the creation of the netboot image.

Creating a netboot image

Launch the DeployStudio Assistant and select Create a DeployStudio Netboot set from the menu.  Read the service information window and continue to the next screen.

Netboot Creation Window: Name the image

Give the system a sensible name, UID, Language and time server.  Continue to the next screen.

This windows allows you to specify a particular server to connect to as priority, along with an alternative – if you were to have a master and replicator DS server.  The syntax this takes is as follows:

https://ServerName.com:60443

The authentication screen allows you to enter a default username and password for logging into the netboot image.  Be warned that entering a default user and filling in the password field means that any time the netboot image is loaded, these fields will be pre-populated and the operator will be able to launch which ever workflows they wish.

To get around this, you can simply disable the netboot service from the Server Admin tool.  This is the advised approach regardless of pre-populating the user and password fields.

There is also an option here for a VNC username and password.  This is here so that admins can remotely connect to the netbooted client and view the status of the deployment.

Once you have made your choices here, move on to the next screen.

The options window allows you to select what extras you want to include into the netboot image.  Some package installers require the use of Python or Ruby so it may be an idea to include those in your image.  Make your choices and move to the final screen.

It’s important to leave the destination location as the default:

/Library/NetBoot/NetBootSP0  <– that’s SP zero, not an O.

If the location doesn’t already exist it will be created.  Click continue and that’s the netboot image complete.

##Important:  Once the netboot image is ready you will need to start the netboot service from the server admin.  This process was described in the previous section; Configuring the server pre DeployStudio.##

An overview of the DeployStudio Admin tool

The DS Admin tool allows us to create the workflows, which we will use to deploy Lion, packages, scripts files and folders, etc. to our client machines.  Down the left hand side of the utility we have various tabs.

Clicking on Activity will display currently running workflows, their progress and client name.

The Computers tab shows the known computers to the DS, this list can be pre-populated by use of serial number or MAC address.  The advantage of this being that we can assign computer names, IP addresses and other things to specific MAC addresses/serial numbers.

The workflows tab will be the most frequented tab of the utility.  This is where we can create our own workflows, as depicted in the below screenshot:

An Overview of the DeployStudio Admin tool

The featured workflow in the screenshot is fairly complex, partitioning the disk, installing the OS, copying files, installing software, and finally running the software update utility when the system boots in for the first time.  We will look more at building workflows in a later section.

The Masters tab lists the captured and ready to be rolled out Lion images.

The Packages tab details all of the packages that have been uploaded to the DS repository.  It also lists any package sets that will install multiple packages in the one shot.

The final tab, Scripts, displays all of the stored scripts in the DS repository.  It also allows for you to create your own shell scripts for deployment.

Workflows

The master workflow that we will be using contains a partitioning step, which will ready the drive for the installation of Lion and Windows 7.  It is important that Windows 7 is installed last.

By default there are a couple of workflows already created.  Some of these we will use; some of them can be removed from the list.  The ‘Create a master from a volume’ is the workflow used to capture a Lion image on the target machine, which will be used as the master base image of which will be installed on all Macs.  This is ready to go right out of the box and requires no adjusting.

The recovery workflow is a custom one I made that will reinstall a working thin Lion image.  Most useful when testing software installs and needing a fresh image without any software pre installed.

To create a new workflow, have the workflows tab selected in the left pane and then click on the plus symbol in the middle pane at the bottom of the window.

To add new tasks to the workflow, click on the plus sign next to the text ‘drag tasks here’.  This action will open a third pane to the right of the central pane.  This pane shows all of the tasks that can be added to a workflow.  Some examples of these tasks would be install a package, restore an image, create an image, partition a disk and so on.

The documentation for DS is pretty extensive so I won’t go into too much depth here, we’ll just look at a few of the main tasks that can be incorporated into a workflow.

Partition

As the title suggests, this task will partition the drive.  You have the choice of customizing the partition yourself but the task comes with some default options.  For example, you can format the drive for a single Mac OS installation or you can set it up for a dual installation of Mac and Windows or even a triple boot Mac, Windows and Linux!

Adding the Partition task to a workflow

When choosing a dual or triple boot partition using the sliders, you can easily adjust the size of each partition.  Mousing over the partition will display a pencil icon in the upper right corner of the partition which allows you to edit the title of said partition.

From the screenshot above you will note a couple of other things.  The first is that you have the option of choosing the target disk for this action to be performed on.  To fully automate the deployment process, it can be a good idea to change this from ‘user selected’ to first available disk.

The second item to take note of is the check box at the bottom of the window labeled ‘Automate’.  Checking this box will automate this step and require no interaction from the user.

Restore

This task restores an image to a partition.  As you’ll see below, there are many options for configuring on this task.

Adding the Restore task to a workflow

From now on, the target volume can be set to ‘previous task target’.  We need to select the type of file system the image was created in, usually HFS and then obviously select the image to be used.  These images, or masters as DS refers to them as, are the images that would be captured using the default ‘Create a master from a volume’ workflow.

The rest of the options are pretty self-explanatory.  We can change the name of the volume if we want to, but seeing as we named it something sensible in the previous Partition task there is no need to rename.  The only option I changed here was to uncheck the recovery partition checkbox, as we are unable to work with multicasting.

Ensure that the automate checkbox is ticked and move on to the next task.

Hostname Form

This task is optional.  It allows you to name the machine.  If you have prepopulated the computers tab within DS with either the serial number or MAC addresses of the Macs then when this task is displayed, the name given in the Computer tab will already appear as default name.

Unfortunately you are unable to automate this task.

Package Install

As the name suggests, this task is for the installation of software packages.   You can either install singular packages or use a package set to install multiple items.

This task is fairly straightforward.  As with every other task, select the drive you wish to install the software to and then select the software item or the software set to be deployed.  As you can see from the screenshot, you have the usual check box for automate, and a second one for postponing the item/set until the first boot.  Selecting this check box will copy the installers onto a temp directory on the local disk and will invoke them upon the next reboot.  You also have a check box to ignore failures, this can be useful if an item installs but has some loss of functionality due to lack of Internet connection or user interaction.

Adding a Package to the workflow

To create a package set select the Packages item from the left hand windowpane and click the plus sign from the bottom of the pane.

The packages tab from the DS Admin tool

You can now add packages to these sets by dragging items from the main packages tab and dropping them on the name of the set you wish to add them too.  We’ll look at how to add software to the DS server in the section titled Repositories.

Repositories

By default, the DS repositories are stored in /Shared Items/Public/DeployStudio/.

The repository directory

This is where we need to place items that will be used within the deployment.  There are a few folders to take note of; Packages, Files and Scripts.  These all link back to the DS Admin tool we just looked at.  To import software we need to have the .pkg/.mpkg’s stored in the packages folder.  Similarly, if we want to use the scripts or the copy files tasks in our workflow, we’d need to have the files and scripts located in the appropriate folders.

Installing Windows 7

We will be using MDT 2012 to install Windows 7.  I have created a specific Windows to mac Task Sequence which runs much the same as any other TS.  The TS runs a diskpart command which tells setup to install to the third partition as Mac uses the first.  The only other change to note here is that the Bootcamp drivers could not be deployed conventionally as Out-of-the-box drivers, but were instead deployed as an application.

Apart from these two modifications, the roll out is the same as any other.

References

DeployStudio has a very detailed guide that includes walkthroughs.  It can be found here:

http://web.me.com/driley/web/deploystudio_files/DeployStudio_Guide.pdf