Re-execute the UserData script in an AWS Windows Instance

Bootstrapping is an awesome way of customising your instances in AWS (similar capability exists in Azure).

To enable bootstrapping, while configuring the launch instance, in Step 3: Configure Instance Details scroll down to the bottom and then expand Advanced Details.

You will notice a User data text box. This is where you can provide your bootstrap script. The script will be run when your instance is first launched.


I went ahead and entered my script in the text box and proceeded to complete my instance configuration. Once my instance was running, I initiated a Remote Desktop connection to it, to confirm that my script had run. Unfortunately, I couldn’t see any customisations (which meant my script didn’t run)

Thinking that the instance had not been able to access the user data, I opened up Internet Explorer and then browsed to the following url (this is an internal url that can be used to access the user-data)

I was able to successfully access the user-data, which meant that there were no issues with that.  However when checking the content, I noticed a typo! Aha, that was the reason why my customisations didn’t happen.

Unfortunately, according to AWS, user-data is only executed during launch (for those that would like to read, here is the official AWS documentation). To get the fixed bootstrap script to run, I would have to terminate my instance and launch a new one with the corrected script (I tried re-booting my windows instance after correcting my typo, however it didn’t run).

I wasn’t very happy on terminating my current instance and then launching a new one, since for those that might not be aware, AWS EC2 compute charges are rounded up to the next hour. Which means that if I terminated my current instance and launched a new one, I would be charged for 2 x 1hour sessions instead of just 1 x 1 hour!

So I set about trying to find another solution. And guess what, I did find it 🙂

Reading through the volumes of documentation on AWS, I found that when Windows Instances are provisioned, the service that does the customisations using user-data is called EC2Config. This service runs the initial startup tasks when the instance is first started and then disables them. HOWEVER, there is a way to re-enable the startup tasks later on 🙂 Here is the document that gives more information on EC2Config.

The Amazon Windows AMIs include a utility called EC2ConfigService Settings. This allows you to configure EC2Config to execute the user-data on next service startup. The utility can be found under All Programs (or you can search for it).



Once Open, under General you will see the following option

Enable UserData execution for next service start (automatically enabled at Sysprep) eg. or <powershell></powershell>


Tick this option and then press OK. Then restart your Windows Instance.

After your Windows Instance restarts, EC2Config will execute the userData (bootstrap script) and then it will automatically remove the tick from the above option so that the userData is not executed on subsequent restarts (or service starts)

There you go. A simple way to re-run your bootstrap scripts on an AWS Windows Instance without having to terminate the current instance and launching a new one.

There are other options available in the EC2ConfigService Settings that you can explore as well 🙂


High Battery Drain on Macbook Pro

I recently moved back to a Macbook Pro, and couldn’t be happier. Don’t get me wrong, for what I was using my Microsoft Surface 3 Pro, it did it brilliantly. It is extremely portable and very fast, an amazing device. Unfortunately it is not built to run virtual machines as it grinds to a stop (I know I know, the newer versions of these fantastic machines CAN handle virtual machines, but mine wasn’t that high spec’d).

Previous to my Surface 3 Pro, I was using a Macbook Pro 13 inch (non-retina) and it served me well. However, my current Macbook is a Mabook Pro 15 inch (retina) and with dual Graphics card. It is amazing. With 16GB of RAM, and an i7 processor, it handles anything I throw at it. And the graphics is breath taking, a 4K resolution on a laptop!

However, one of my gripes from day one has been the high battery drain I had been experiencing. Comparing battery life with my colleagues, I found out that while their Macbook Pros would last for at least 5 hours with 100% charge, mine would die in under 3 hours! This either meant that I had been shuffled a defective device by lady luck, or there was some setting I was unaware of. I decided to use the latter of the possible causes and started my investigations.

macOS Sierra (and previous versions) have a native “task manager” called Activity Monitor. This is an amazing utility, as it not only tells you about your CPU and Memory usage, but also shows the impact each application has on your battery.

After viewing the applications under the Energy tab for a few minutes, I didn’t notice anything out of the ordinary, however there was something peculiar happening with the Graphics Card. The High Performance Graphics card was always in use. From what I had previously read, the high performance graphics card on Macbook Pro’s is extremely power hungry, which could explain my high battery drain.


Using Dr. Google I found some articles, which stated that if Automatic graphics switching is disabled under Energy Saver in System Preferences, macOS will use the high performance Graphics Card 100% of the time. I quickly checked my settings and the Automatic graphics switching was unticked!



I placed a tick beside Automatic graphics switching and then went back to the Activity Monitor utility. This time it showed the Graphics Card as Integrated 🙂


I then proceeded to run my Macbook on battery, keeping an eye on the battery. This time around, the battery didn’t drain as quickly, and the fan noise that I had previously been experiencing (due to the High Performance Graphics card being used) wasn’t present anymore.

I hope this helps others who might be experiencing similar issues with their battery usage. Do note that this is a possible solution for all Macbook Pro’s that have dual Graphics Card but not applicable to those that have only one.

Error rebuilding MIMWAL – File MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll not found

A few days ago, I was going through the steps for compiling MIMWAL, as listed at and came across an interesting problem.

After I had rebuilt my Visual Studio package, I went to run Sign.cmd and kept getting the following error message


Error: File “MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll” Not Found. You need to compile WAL solution first! Make sure you use REBUILD Solution menu. Aborting script execution…

This was quite bizarre as I had not deviated from the steps listed in the above mentioned article. It was time to put on my Sherlock hat and find the culprit behind this error!

I opened the SolutionOutput folder and compared the contents to what was shown in the article and found something interesting. The dll mentioned in the error was indeed missing!

Also the file MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.pdb was missing.

This meant that there must have been an error when rebuilding the package in Visual Studio. I alt+tabbed to my Visual Studio screen and in the output pane, saw something interesting. It showed that there had been some issues while copying  MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll to the SourceOutput folder.


The error

WorkflowActivityLibrary -> C:\MIMWAL-2.16.1028.0\src\WorkflowActivityLibrary\bin\Release\MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll
1> Does C:\MIMWAL-2.16.1028.0\src\SolutionOutput specify a file name
1> or directory name on the target
1> (F = file, D = directory)? ?

seemed to indicate that when Visual Studio was trying to copy the two missing files, it hadn’t been able to determine if the destination folder  SourceOutput was a directory or a file. This resulted in Visual Studio skipping the copy of these files. Doing some investigation, I found that the MIMWAL source package didn’t contain a .\src\SourceOutput folder. This explained why Visual Studio was showing the above warnings.

Based on my findings, I found two solutions that helped resolve the issue

Solution 1

Rebuild the Visual Studio Package again. On the second try, since the SourceOutput directory now exists, the files will be successfully copied.

Solution 2

Before rebuilding the MIMWAL package, create a subfolder called SourceOutput inside the src folder

My preference is for Solution 2 as it means that I won’t get any errors.

After successfully rebuilding the MIMWAL package, I ran sign.cmd and this time around – Success! I got the expected result.



I hope this blog helps anyone else who might be having issues with compiling MIMWAL and running sign.cmd