Log in

4th May, 2017

Last stop, all change!

Baaaad Apple!

Hmmm..... I just ran into something a bit odd while I was faffing about adding Apple IDs to my KeePass store.

A Long Time Ago, In A Student Flat, Somewhere Down South......

Yeah; at some point, way back when, I ended up with two Apple IDs... not that they were necessarily Apple IDs back then; I *think* I had an account I used for accessing Developer-y type stuff, which I then forgot about, and later I signed up a different email address for my iTunes account.... and maybe at some point I *think* I remember Apple converted the Developer site logins into Apple IDs.... or something like that. I also, at some point, gained access to the Developer-y site using the originally-iTunes-only account.

Anyway; yes, two Apple IDs, which I've now transferred out of Firefox password management and into KeePass.

So far, nothing odd.

But then I managed to do something that I didn't expect I would be able to.... and which I did completely by accident..... I clicked on the "Account Settings" link on developer.apple.com, where I was logged in with the originally-Developer-y account.... and got sent to the Account Settings page on appleid.apple.com for the originally-iTunes-only account....

Now; I did work out that this was because I had signed in to appleid.apple.com using the iTunes-y account then logged in to idmsa.apple.com (the login portal for developer.apple.com), and so had managed to get into a situation where I had two tabs running on two different Apple ID sites using two different Apple IDs....

It just struck me as rather.... just *bad*, I guess, that whatever token Apple use to say "you're logged in" doesn't provide some sort of additional validation that you're logged in with the correct Apple ID before it gives you access to an Apple ID's Account Settings.....

And I was starting to wonder if I was just being reactionary because it was weird and unexpected behaviour, and that its actually to the point of not even really being sure that its a big deal....

To be honest, it probably *isn't* a big deal... afterall, to have access to areas that are of restricted access, I have to have left the Apple ID logged in... which means that even with*out* going though the idmsa portal, I can just go to appleid.apple.com/account/manage and I'm in the self same position...

It just feels really... *off*.

Maybe its because Microsoft's "Passport"... or whatever they call their Single-Sign-On these days... ("Live ID" perhaps...?) is just that; you can sign in to a single ID in a particular Firefox instance... if you want to access a different ID's email (for example), you have to go to another browser, start a new Firefox instance with a different Profile, or (my preferred option) open a Private Browsing window..... so maybe I'm just expecting a bit too much and its perfectly reasonable for a login through idsma.apple.com to NOT clash or clobber a previously-logged-in ID made through appleid.apple.com...?

So, I just found myself adding a new entry to my Win7 Explorer context menu. Nice and easy one would say. And for the normal "right-click a folder icon" case, it is; setting the command to "d:\path\to\run-program.exe" "%1" and invoking the menu entry does exactly what you would expect; starts "run-program.exe," passing it the right-clicked directory's path.

The problem is that for this particular purpose, it makes sense to have the same entry appear in the context menu that appears when you right-click the empty space between the icons when you are in the folder you want to invoke the menu entry for...

Superficially, this is easy; as well as the Shell key under which the right-click-an-icon context menu entries are defined, HKEY_CLASSES_ROOT entries have a Background\Shell key which defines the right-click-in-the-empty-space context menu entries. So all that needs to be done is to duplicate the structure that is working for the right-click-an-icon context menu under Background\Shell.

As I said, superficially its easy!

However.... although this is enough to make an entry appear in the context menu, trying to invoke the entry results in a rather useless error message:

This file does not have a program associated with it for performing this action. Please install a program
or, if one is already installed, create an association in the Default Programs control panel.

Not very useful or helpful; afterall, I invoked the action using a program association from Explorer!

So what's gone wrong?

Well, after a bit of twiddling around, I've come to a couple of conclusions:

  • Despite being superficially identical to the right-click-an-icon Shell key, Background\Shell is processed differently "under the hood".... don't ask me why though; its a bit weird (or a bug)
  • For Background\Shell (and presumably any other Background\*whatever* entries), the standard "%1" (that's a one, not a lower-case L) parameter placeholder that was inherited from DOS Batch Files simply doesn't work, nor does the alternative "%L" (whether upper- or lowercase) placeholder.
  • What does work is to use the "%V" form (which is tied in to Microsoft's terminology and means "Verb").

In short then, it may be best to try to remember to just use "d:\path\to\run-program.exe" "%V" in any and all command entries that deal with filesystem entities, rather than %1 or "%1"! But be warned: Your mileage may vary.

I should say that that I'm not recommending that without testing first; the "%V" form works perfectly well when invoked from Explorer for single and multiple file selections.

FYI: The placeholder appears to be case insensitive, as both upper- and lowercase "%v" work as expected, HOWEVER, it may be that upper-and lowercase "%L" placeholders are different, as there is mention (see below) of the uppercase ("%L") form being quicker (atleast on 32-bit Windows systems with the 16-bit Windows subsystem available), as it avoids probing for the invoked application's type. It is unclear whether the application type probe occurs on 64-bit versions of Windows that cannot execute Win16 code.

I have no idea why this information is not in the MDSN article itself... :-/ For reference (from a comment by Chris_Guzak against an MSDN page @ archive.org, via superuser.com), the different 'command' parameter placeholders are:

    %* – Replace with all parameters.

    %~ – Replace with all parameters starting with and following the second parameter.

    %0 or 
    %1 – The first file parameter. For example 
         "C:\Users\Eric\Desktop\New Text Document.txt". Generally this should be in 
         quotes and the applications command line parsing should accept quotes to 
         disambiguate files with spaces in the name and different command line 
         parameters (this is a security best practice)

    % (where  is 2-9) – Replace with the nth parameter.

    %s – Show command.

    %h – Hotkey value.

    %i – IDList stored in a shared memory handle is passed here.

    %l – Long file name form of the first parameter. Note that Win32/64 applications
         will be passed the long file name, whereas Win16 applications get the short
         file name. Specifying %L is preferred as it avoids the need to probe for 
         the application type.

    %d – Desktop absolute parsing name of the first parameter (for items that don't
         have file system paths).

    %v – For verbs that are none implies all. If there is no parameter passed this 
         is the working directory.

    %w – The working directory.

I sort of half-remembered having also seen "%U" used as a placeholder, but after a bit of testing using nircmd's qpop function to output the placeholder values, it appears that this was just plain wrong!! (Although whether it was %U or my memory that was wrong is unknown!! ;-) )

Windows terminology uses "language" to refer to what a Linux bod probably thinks of as a "locale"; the language choice does more than just specify which dictionary to use, it is the basis for date and time display, text sorting order, the keyboards the user can choose, and it even stipulates which characters are considered letters, spaces, etc (although whether *that* one is true on Windows, I don't know; it does on Linux though).

Now, to be honest, I'm only opening with that paragraph so that I can justifiably refer to "locale," *not* "language," for the rest of this post.

So why am I interested in locales on Windows today?

Well, because I've come back to test-building a Windows 8.1 system in a VM before I bite the bullet and (***finally***) reinstall my main laptop. (*Quite* how its still functional is beyond me... it seems to have settled down at a certain level of broken!).

(Why a new test-build? Well, because (1) the previous one is *so* outdated that as to be irrelevant; most things I'll be manually installing have been updated, and quite a few to new major-version releases... (and 2) the world of Chocolatey has moved on, and most of the packages that *were* stuck in the mire of the Chocolatey people getting package-validation,-testing-and-approval up and running are now un-stuck, and point (1) applies to a great many of these, but also, unfortunately, the period of "stuckness" means that a *lot* of packages are now *badly* outdated relative to upstream, presumably because package moderation appeared to be stalled completely, so the once-maintainers moved on)

So, your might be asking again, why am I interested in locales on Windows today?

Well, because I have multiple keyboard layouts set up on my machine, and because on Windows 7, I can give each of them a different coloured icon... although I don't often *use*, for example, the UK layout, it *is* occasionally useful (ie, if mum needs to use my machine for something), and so that gets a red icon, so I know at a glance towards the systray if the reason my password isn't working is because I'm on the UK layout and so typing, eg, '£'-signs instead of '#' characters!

And because this functionality doesn't appear to exist in Windows 8.x.

NOTE: I'm talking here about the "Language Bar," which displays either as a small toolbar or as a small keyboard icon to the left of the systray, I am *NOT* talking about the new-for-Win8.x language indicator that is located next to the clock and displays the language selection in an abbreviated textual form (ie, it shows 'ENG' on an English-language system). The former is the "legacy"/"win32" version of the language selection interface and has been around for a few versions of Windows now, the latter is the "Metro"/"Modern" interface and doesn't (to my knowledge atleast) allow any kind of customisation.

I know it sounds like a little thing, but honestly, its the one I *keep* running into in Win8, and even just today while I've been installing stuff, this useless indicator icon has been sitting there mocking me.....

I *have* successfully worked around and/or gotten used to all the bits of Windows 7 that initially did my head in... the most significant being that the Start Menu is next-to-useless if you install more than about 2 things.... the non-cascading-ness preventing any "discoverability" (as Microsoft themselves termed it in relation to the wonderful new Windows 95 Start Menu!)... and discoverability is *really* important to me; I have a couple of *hundred* things listed to install on this Win8.x system, and when I need a to do something in a hurry, I can usually only remember that I've "got something that does that" somewhere on the machine! I need to see the names to remember what they do; there is no way I could *guess* have the names of these things!

And, thanks to Classic Shell, I got my nice cascading Start Menu back, and it works perfectly on Win8.x too!

The only other really issue I have with Win8.x is just how much MS waved the 'ugly stick' over it!! When Vista was launched, we actually had an out-of-the-box nice-looking Windows, after all those years (and the lovely little hack for XP that enable unsigned themes to be used); indeed, Vista being pretty was about the only thing that even remotely *tempted* me to move to it (then I found out about that XP hack).... moving from Win7 to Win8.x is *jarring* to say the least, and it hasn't grown on me at *all*....

Luckily, I'm not alone in *loathing* the ugly Win8.x duckling, and there *is* a Fairy Hackmother out there who waved their magic wand and created Aero Glass for Windows 8.x+, and suddenly we have a pretty Windows 8.x swan!!

So I thought I'd see if MS has *really* broken the indicator, or if they'd just broken the method for *configuring* it..!

A post on SuperUser.com suggested that perhaps it was the former, so I had a bit of a play.

Now, this whole keyboards, locales and users combination is a bit... well, lets just say that it doesn't exactly feel *elegant*! And MS appear to feel the same; their documentation is.... rather lightweight and vague...!

The upshot of the whole caboodle is that to change the indicator icon, we have to understand how three three sets of inter-referenced registry keys relate. Those keys are:

  • HKEY_CURRENT_USER\Keyboard Layout\Substitutes
  • HKEY_CURRENT_USER\Keyboard Layout\Preload
  • HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon

I should point out that, while I'm only interested in keyboard layouts, Windows is actually dealing with "input methods" and these aren't limited to just the traditional physical keyboard; they include the virtual/touch keyboard, handwriting input and (presumably) predictive text.

So if you catch me talking about keyboard layouts instead of IMEs, you know what I really mean! ;-)

Anyway, IMEs each have an identifier (I'm calling one of these an "IME ID") associated with them, and in the Substitute key, it is these IME IDs that we assign to items as values. The Substitutes key is used to assign a user's selected IME(s) to a user's selected locale(s). The item values in the Substitutes keys refer to the system's IMEs, the item names are the user's IMEs.

The Preload key specifies an ordered list of the user's *prefered* IMEs, with the item named "1" denoting the user's default IME. Preload item values refer to the user's IMEs (assigned in the Substitutes key).

And the LayoutIcon key relates layout IDs to icons. This exists (or rather, I know it atleast exists after you've assigned an alternate indicator icon) on Windows 7, but if you create it, it also works on Windows 8.x! :-) This key uses a different structure to the Substitutes and Preload keys, but also refers to system IMEs.



Right, so thats nice and simple then, yes?



Well.... no, unfortunately... you see, as well as having item values under one key referencing item names in another, there's a nice lump of symbolic meaning in the values themselves... Which brings us back to IME IDs.

My Windows 8.x VM, is using the United Kingdom locale, and has 3 IMEs assigned to that locale;

  • United Kingdom
  • Faerieality (UK English)
  • United States-International

(The Faerieality one is my homebrew layout (built with MS's Keyboard Layout Creator), which is based on the US layout and has all sorts of extra characters via various key combinations and sequences that make sense, quite possibly only to me!)

The Substitutes key contains these items (name -> value);

  • d0010809 -> 00020409
  • d0020809 -> a0000809

But my Windows 7 install (which has (almost) the same locale and IMEs (except it has the basic US IME rather than the International variant), has as *its* Substitutes key;

  • 00000809 -> 00000409
  • d0010809 -> 00000809
  • d0020809 -> a0000809

If I pull out the IME IDs, there are 4 in total;

  • 00020409 is US International
  • a0000809 is Fae UK
  • 00000809 is UK standard
  • 00000409 is US standard

But if we consider only the last 4 characters, we can see that;

  • 0409 only appears in the "US" IME IDs
  • 0809 only appears in the "UK" IME IDs

These values are also present in the Substitute item *names*, so it appears that the last four characters of the IME ID identify a locale.

It seems we can think of part of the IME ID as being a sort of reference against an list of locales, but what about the rest of the ID value?

In order to figure this out a little better, I added Welsh as a locale, then assigned the US Dvorak IME to it, which gave me another Substitute value;

  • d0010452 -> 00010409

Which suggests that 0452 is the Welsh locale, and reinforces the idea that </code>0409</code> is the US locale... but it also suggests something else... if we consider the second through fourth character of all the US IME IDs;

  • 000 is the basic default US
  • 001 is US Dvorak
  • 002 is US International

Then the obvious conclusion is that this *too* is a reference, this time to a list of IMEs *belonging* *to* a locale... and a reasonable design decision would be to use atleast 2 characters for this purpose (allowing 256 IMEs within some locale-specific grouping), or even all 3... although 4096 might be a lot of IMEs to group together...!

It *could*, of course, just be that the second (and maybe third) character is always 0, is reserved for future use or I just haven't run into it being used.

It doesn't really matter a great deal to us if its only the fourth character, or a group of three; this allows us to differentiate different IMEs from the same locale.

But what about the 'd' and the 'a' that appear in the Substitutes list?

So far as I can see, the first character of an IME ID is a "flag" character. I've only seen it have three values;

  • '0' which seems to mean "this is a completely normal, default IME ID/locale combination"
  • 'a' which I've only seen for my custom keyboard, so it probably means "this is an OEM IME that is not part of Windows" (which probably means it implies "contact the OEM for support")... (maybe 'a' stands for "addition"??)
  • 'd' which seems to get used in a Substitute item name for all but the first mapping relating to the locale. As I've been typing this, two possibilities have occurred to me;

    • it could denote something like "do not fall back to this IME" ie, when the prefered IME is removed
    • it could relate to support for codepages in the virtual-x86 MS-DOS environment, but I'm on 64-bit, so the DOSVM doesn't exist, and the GUI for 'select codepage' isn't present on my Win7/x64 install, so I can't try see if this is the case

Finally, it should be noted that, even though my Windows 8.x VM has (essentially) the same IMEs assigned to the same locale as on my Windows 7 system, it has one fewer Substitute item... And the way this appears to work is that;

  • When a user adds a new locale, the system's default IME for that locale is automatically assigned as the user's default IME for their new locale. For the UK locale and its default IME, this results in a Substitutes entry for 00000809 -> 00000809, but because this is a no-brainer, Windows doesn't bother with the Registry entry. It *does*, however, add the IME to the Preload list.

  • On my machine, initially I replaced the UK IME with the US one, and it appears that if you assign any other IME to the locale and remove the default IME all in one go (ie, you open the Text Services and Input Languages panel, add a keyboard and remove the other without clicking "Apply" or "OK"), then;
    • The removal is done first; Windows takes the relevant IME out of the Preload list and (presumably) removes it from Substitutes if there is an entry there for it.
    • The system then adds the new IME, mapping the user's default IME for the locale to an IME that *isn't* the system's default IME for the locale.

      Obviously Windows needs to remember this mapping beyond the current login session, so it has to create an item in the Substitutes key to record the mapping (in my case, the user's default UK IME, 00000809 maps to the system's standard US IME 00000409).

    • Finally it adds the new user IME to the Preload list.
  • If the user subsequently adds back the IME that was removed (the system's default IME for the locale), Windows has a somewhat peculiar scenario to handle; the entry in Substitutes for the user's default IME for the locale (in my case, 00000809 -> 00000409) has already *got* am IME mapped to it (the standard US IME in my case), so Windows now has to add an entry to Substitutes for the system's default IME for the locale as that user's Nth additional IME for that locale (giving a mapping of d0010809 -> 00000809 on my Win7 machine).



Right, are we confused yet? I know I was by now!! (Especially after looking at my Windows 7 config!)



So after all that, how do we change the icon colour?

Well, now we have a handle on all those IDs, we can put it together...

On Windows 8.x, we navigate to HKEY_CURRENT_USER\Software\Microsoft\CTF and if the subkey HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon doesn't exist, we create it.

Next, we create a subkey for our locale, so for the UK locale (the locale id being, as we've worked out, 0809), we create HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809

The final subkey(s) to create, are for the IME's the user has assigned to the locale;

  • First up, we need to consider the default IME for the locale. This is the "missing" entry that makes my Windows 8.x VM's Substitute list shorter than on my Windows 7 system.

    • We need to determine this IME ID, so we have to go through the Preload list and cross-reference the item values with the item values (not the item names) on the Substitutes list. Unless you've messed around with your IMEs like me, you'll come across an item value from the Preload list that doesn't correspond with any item value in the Substitutes list; this item value is the missing IME ID for the locale.
    • Now we know the IME ID, we can create the LayoutIcon\locale subkey for it.

      On my Win8.x VM, the IME ID 00000809 is not a value in my Substitutes list, so I create HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\00000809

    • Now we need to add the other IMEs for the locale. This is much less faff; we just create a subkey for each of the other item *values* in the Substitutes list whose item *name* refers to the locale, so on my system, for the United Kingdom locale, I
      • Skip the entry d0010452 -> 00020409, as it references the Welsh locale (0452)
      • Create HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\00020409 and HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\a0000809 as the mappings d0010809 -> 00020409 and d0020809 -> a0000809 both refer to locale 0809

Now (at long last!) we can assign some icons!

Starting with the UK layout (00000809), under HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\00000809, I create two items:

IconFile String REG_SZ C:\Windows\system32\msctf.dll
IconIndex 32-bit DWORD REG_DWORD 0x17 (23)

And that's it! We've assigned an icon to one of the IMEs.

To check that this has worked (its really easy to mis-count the number of zeroes!), it is necessary to log off and log back on again. (Bear with me just this once; there is a way to do update the indicator icons while logged in, but this is easier for a one-off. I promise I'll tel you the Better Way in a minute).

Having logged back in, I can see in the IME picker that I have a little red keyboard icon for the UK layout. If you didn't change your default keyboard's icon, you'll have to click the indicator icon to see the menu, where the icon is also changed.

So now for my other two IMEs

  • HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\00000809
    • IconFile -> C:\Windows\system32\msctf.dll
    • IconIndex -> 0x12 (18)
  • HKEY_CURRENT_USER\Software\Microsoft\CTF\LayoutIcon\0809\00000809
    • IconFile -> C:\Windows\system32\msctf.dll
    • IconIndex -> 0x15 (21)

Now, the most annoying thing about this whole rigmarole (once you've gotten used to the different IDs and keys and things, anyway) is getting Windows to update the icons that are actually being used! Logging-off-and-on-again gets very tedious very quickly if you're just playing with icon choices! So I had a bit more of a think, and I had an idea; what would happen if we hid the IME selector then un-hid it? We *can* still do *that* using the GUI; we just have to know where to look!! So;

  • On the Start Screen, type

            change input

    You should see "Change input methods" in the list of search results; click it.

  • In the window that opens, in the left-hand column is a link for "Advanced settings," click it.
  • Now go down to the section "Switching input methods;" on the right is a link for "Options;" click it.
  • I *know* its a lot of clicking; unforunately I can't help how MS have buried this...
  • Anyway, a new window ("Text Services and Input Languages) should appear (looking rather a lot like an old fashioned control panel applet, how quaint!), with a "Language Bar" tab that has a "Language Bar" section containing some radio buttons ("Floating On Desktop," "Docked in the Taskbar," and "Hidden."
  • Note which of the radio buttons is currently pressed, then press the "Hidden" button and click Apply. Your IME selection doo-dah should have gone.
  • Now press the originally-pressed radio button and Apply again, and the doo-dah should come back, but with the icon change(s) you made in the Registry applied! Happy days! ;-)

Hopefully you can see why I said it was easier for a one-off change to just log out-and-in; this approach is *really* useful when you're experimenting, but a real P-I-T-A for a quick tweak!

Now, I have to admit that I cheated a little bit with the icons I used for testing this, and just used the values from my Windows 7 system (in my defence, I was only seeing if I could get some different icons to show at that point).

Icon Palette

But, to make up for my cheating, here is the Windows 7 icon selection palette for msctf.dll (which is where these keyboard icons live). If you count down the columns, you will see that if we look up the icons I used, the IconIndex value is easily derived;

  • The red icon is 24th in the palette, but computers start counting at 0; in computer-think, IconIndex = 23.
  • The purple icon is 19th, so its IconIndex = 18
  • The orange icon is 22nd, so its IconIndex = 21

Oh, BTW, if you don't create a key for a particular IME's ID, it will receive the default icon (as per the US Dvorak IME in the image below).

In the end, the icon is just a normal Windows icon, so if you can determine the IconIndex to use, then you can specify any icon from any icon-containing file you like, for example, using;

  • IconFile -> C:\Windows\System32\user32.dll
  • IconIndex -> 0x6 (6)

would set the UAC Shield as an IME's icon!

Multicoloured Keyboard Icons

Dad's home after day surgery

Well, that's over then, phew!

Dad went in to LGI at some ungodly hour this morning for day-surgery, and is now home.

Basically, when they operated back last year, in order to get in to access the cancer, they had to break or cut his jaw (dunno which), which they then put back together with screws and a plate... but for a while now, he's been bother by what is apparently one of the screw heads, which was appearing as a lump on/near his jawline... so presumably atleast *that* screw is now not there.... apparently they don't normally take any of the screws out, so who knows how much is left!

Apparently they haven't found any loose screws though.... -innocent-

Update on MultiSim issue

This is a follow on to this post.

OK, so, having faffed about why the runaway ApplicationWebServer.exe process and decided what I was going to do about it, I accidentally left the service set to start automatically... and then three things happened.... the two main ones being (!) that it was Patch Tuesday, (and 2) the performance of VMWare tanked (the third was a "silly me forgot to do something" that required another reboot)....

(VMWare performance is one of those specific areas I mentioned that is degrading on this machine, and after a while my Win8.1 pre-reinstall testbuild VM becomes slower than a slow thing with its slow hat on... and it only gets better after a reboot)

.... now, I can't remember what order these three reboot-requiring things happened; I may have rebooted to fix the VM performance first, or it might have been Patch Tuesday's Windows Update reboot.... and I really haven't a clue where that "oops" reboot happened.... but I presume my first reboot was to fix VMWare, because I wouldn't have thought the machine would have been up long enough by the time I did the second reboot for VMWare performance to have tanked... it does usually take, well, longer than the machine would have been up between the first and second reboots anyway....

... So anyway, I had to reboot... and after a while I found myself poking around Task Manager again (completely unrelatedly) and I noticed (a) ApplicationWebServere.exe was running (and b) it was using no CPU and it was consuming about 1.5 meg of ram, not the 15 meg it had when it was a runaway... So I left it set to automatic, and got on with whatever it was that had prompted me to look in Task Manager in the first place.

Some time later, I had to reboot again . After the machine was back at the desktop and everything had finished loading, I realised the fan was running again.... back into Task Manager, and guess what? Yep! Its my old friend ApplicationWebServer.exe using up a whole CPU core's worth of cycles and its back to 15-ish meg memory usage.... "strangerer and strangerer" I thought.... but I knew I had another reboot left to do, so I just left it alone, CPU usage and all, did what I had to (which wasn't a 5 minute job, mind) and, having had a quick peek to see what it ApplicationWebServer.exe was up to (still runaway, as you probably guessed), rebooted for the third time...

And again, back on the desktop, everything was up and running, except for the fan.... just a nice silent machine, like its supposed to be...! Task Manager confirming that again, CPU use for ApplicationWebServer.exe at zero, memory around 1.3 meg...

So I honestly don't know what is up with it... I can't decide whether it was a Windows Update that caused it, then a Patch Tuesday Windows Update that fixed it, or if sometimes ApplicationWebServer.exe needs to run with mad amounts of CPU use (although if that were the case, I would have expected it to have stopped doing so, given that it had a couple of hours running like that before I rebooted for the last time) ORrrr if its just a weird glitchy bug in ApplicationWebServer.exe that means it will always tend to have these weird runaway instances after a reboot..... but then, why would it also have the runaway behaviour every time I restarted the service?

Its all very strange, and I'm at a loss to explain it.

I'm leaving the original post in place (with a link to this update) so that if someone does happen to stumble across either of them looking for information on this weird little problem, they get all the info I've posted


NOTE: There is a further post following up on this issue here.


This entry details a situation where, after various software updates, an "ApplicationWebServer.exe" process associated with National Instruments "MultiSim Blue, Mouser Edition" is using excessive CPU time.

If you are trying to figure out how to sort this, I've included a Step-By-Step-Guide. I think it should make sense without reading the rest of the post if you don't want; you can read it by following this link... hopefully it will help.

So, as a consequence of a combination of a spiralling Windows 7 install and the NUC/Windows Server 2012 R2 debacle, I'm in the process of figuring out a new Windows 8.1 installation for my main laptop.

I've *also* been putting together an electronics buy, trying to get bits for various projects for the lowest price while also getting free shipping on the orders... which is a pain of a process, since it means trawling through ebay, Amazon, RS and Mouser (the latter of whom have possibly the least useful website for looking around for bits you've ever met....! Although having just gone on it, they seem to have changed things a bit, so that comment may (or may not...) be a bit outdated!)....

Anyway, sometime in the last week or two, I got a banner ad for 'Free MultiSIM BLUE electronic design software from Mouser'... I've got a few free electronical tools on my Windows box... Cadence OrCAD Lite, Eagle Light, Fritzing, PCB Library Expert Lite, TinyCad, and RS's DesignSpark (which presumably provided the impetus for Mouser to offer MultiSim), as well as a couple of stripboard layout tools (DIY Layout Creator and VeeCAD Free Edition), so this piqued my curiosity because, well, I'm still looking for something that covers everything I want to be able to do... generally my usage can be summarised thus:

  • I don't want to be spending money I don't have on software that is mostly for occasional hobbyist use
  • For small projects on stripboard, I tend to use TinyCAD for schematic side of things, and I use DIYLC and VeeCAD as a pair; the Free version of VeeCAD supports NetLists, so can be used to verify that the layout and the schematic match up, but its board view is black-on-white and very, erm, *dense* when there are links, components and stripbreaks in close proximity (for 'dense,' read "bloody horrible to read/use") so I use DIYLC for doing the majority of the actual layout, as it uses colour, and also because it lets you make stripbreaks between holes, rather than on them, which can be useful for getting the board size down, even if its a bit of a pain (literally; I get sore fingers from scraping away the copper every time I do this!) to implement...!
  • For the tiny bit of PCB design I've done over the last few years, I rather like DesignSpark, mostly because you can do 3D views of PCBs and it is really useful to be able to visualise component heights and shapes if you're trying to work out how to squeeze something into as small a space as possible while maintaining clearances for airflow, etc (which I was... that project had to be hide-away-able in a small void I'd found within my car's dash assembly)
  • I really should get my head around simulation at some point.... especially if I'm going to realise a couple of my rather more ambitious projects...
  • If I can't do it all in one tool, I would like to be able to atleast exchange data between tools without too many headaches(!)
  • I need to be able to "talk Windows" when it comes to passing some schematics, etc to other people... this is more a requirement on the non-hobbyist side of my occasional electronical dabblings.... emailing PDFs just isn't good enough... I need to be able to say "install ThisTool", to make a form of collaborative editing possible without OS issues clouding the picture....

Anyways, I downloaded MultiSim Blue and installed it to have a quick look around.... it looks like its probably really useful (once you get over the learning curve.... :-/ ), but I'm not actually trying to use it at the moment; I'm all about 'installation sequencing' and testing at the mo, so we'll see.... but since this is National Instruments commercial grade software wrapped in a bit of Mouser branding, its definitely got potential.....!

Anyway, I updated Windows earlier today and, after the inevitable reboot, I found I had a laptop that had its fan on constantly. This is NOT normal behaviour... this machine usually runs (essentially) fanless, atleast until Firefox decides to run away with a load of excess CPU use...!

Looking into Task Manager shows ApplicationWebServer.exe, which is clocking 13% CPU use... since this is (effectively) an 8-core CPU systen, that's a whole CPU core's worth of processor usage...! Right-clicking this process and choosing 'Open File Location' dropped me into C:\Program Files (x86)\National Instruments\Shared\NI WebServer, so this is definitely part of MultiSim's installation, as I don't have any other NI software.

While looking in Task Manager, I also noticed a number of NI*****.exe processes, so I'm beginning to get very suspicious about MultiSim's installation...

Anyway, I kill the rogue process and the fan stops; nice....! ^.^

But what about all those NI*****.exe processes?

Turns out that MultiSim Setup has installed 12 (yes, that's twelve) "NI something-or-other" Services, and 10 (ten!) of these are set to start automatically, including two of the three web servers its installed....!

The process I killed is the 32-bit version of "NI Application Web Server", the other webservers being (bizarrely on a 64-bit system), an inactive "NI Application Web Server (64-bit)" and an "NI System Web Server".... given a few minutes poking around, I can find no obvious feature within MultiSim that uses a webserver; originally I did think that maybe the help system was using it so NI could be platform agnostic, but the help is just a normal Windows Help file....... :-/

In addition there's:

  • an NImDNSResponder... which its own description says is a "zeroconf advertisement and discovery" service... which, in turn, is exactly what Apple's Bonjour service is (that process is mDNSResponder.exe, btw), and I've already got that running because it installs with iTunes, and I can't be bothered to figure out if it breaks iTunes if I disable it!... surely if you're writing an installer, you can check if a local mDNSResponder exists and can be queried before you install and enable another one...?!?!?!
  • a time sync service.... just a tiny point here, but Windows has an Time Service... and I believe it comes with an Internet Time Service configured out-of-the-box.... has done since XP was new, if memory serves...... so that's more functionality being pointlessly duplicated and enabled out-of-the-box....!
  • and an 'NI Network Discovery" service, which apparently is necessary for zeroconf discovery of devices and services.... you know, exactly what an mDNSResponder is supposed to be for....................................... (I'm not sure there are enough 'period' characters in the world to show how much this one confuses/annoys me...!)
  • finally, I will admit, there are a couple of more 'sensible' services included, such as a license management service and an authorisation service....

Buuuuuttt... and here's the real kicker.... I stopped ALL the NI Services (properly, using services.msc this time, atleast for the ones that would stop when told to... I still had to kill a couple) and MultiSim still works! So does (atleast as far as I tried it, the bundled NI UltiBoard software. Admittedly, I didn't do anything more than place a couple of components in a schematic in MultiSim (and I only started the UltiBoard software), but still, I wouldn't expect to be able to even fully load the software without the licensing and/or authorisation Services, let alone make use of it, even in a small way..........

As a consequence of this (very arbitrary) experiment, it looks as though it may be possible to run "MutliSim BLUE Mouser Edition" without running any of the NI Services that were set up out-of-the-box to 'Automatic' startup... but mileage may vary with this... if you (like me) have looked at those 10 running services and thought "erm, attack surface!!", its probably best to have those ex-Auto Services set to Manual start, and then only start them for the duration of a MultiSim working session (by batchfile 'sc' commands maybe? or some PowerShell....) and to also isolate them from the network as much as possible using your application firewall... Windows Firewall (atleast on Windows 7) looks like it should be able to do this, but I'm running Comodo Firewall, and I can't be bothered to test either right now!

NOTE (To Self): Out-of-the-box, the only NI* process that set to Manual was the 'NI License Server,' while 'NI Application Web Server (64-bit)' was set to Disabled.

Which begs the question; why are Mouser (and therefore NI) distributing a piece of software that bundles so much unnecessary stuff that install with NO NOTIFICATION TO THE USER??? Anyone would think that this was an Apple product (iTunes, I'm looking at you here......)

And as for the chances of a non/semi-technical user (ie, a nominal prototypical 'hobbyist' electronics enthusiast) being able to work out (a) why they have two webservers running (away with the CPU! ;-) ) (and b) how to prevent the runaway one from happening after every reboot, I'd say they are..... looooowwwwwwwwwwwww.......!

Note: To reiterate, if you are trying to figure out how to sort this, I've put a Step-By-Step-Guide at the bottom.

Now, back to my runaway ApplicationWebServer.exe process for a moment.... I've been poking at it a bit more, and (because I've just been killing it), I hadn't noticed that starting it also causes two instances of NIWebServiceContainer.exe to start, as well as SystemWebServer.exe (that is, "NI System Web Server"), which (in turn) starts the "NI Authentication Service" and "NI Service Locator" Services.... I still have no idea what the Application Web Server's purpose is, but its dependencies atleast explain what a few of the Services that are running are doing running!

One final thing to note is that I installed MultiSim a few days ago, and I have definitely rebooted in the interim.... however, NI's auto-updater installed an update yesterday... and the first reboot since that update was the one I performed today after installation of a couple of Windows Updates... which is when the runaway process first became manifest. (I've been using Linux a fair bit recently; enough to have slipped out of the habbit of "always reboot after any update, no matter how small"!!!! :-( ). It therefore seems likely that whatever has caused that process to simply runaway immediately upon starting, it came from either NI's own update or (less likely I think) a Windows Update....

I am (99.99%) certain it isn't because this Windows 7 install is getting flaky; it is still generally stable enough to stay up without a reboot for a few weeks (ie, Patch Tuesday to Patch Tuesday usually), with it being in Sleep overnight, and doing atleast an 8 hour day most days... the 'flaky' still only manifests in very specific ways at this point...

I'm hoping that this issue does affect a reasonable number of people, and that a subsequent software update will fix the errant process... but I'm not daft enough to hold my breathe 'til it happens!!

Follow-up: There is a further post following up on this issue here.

Just in case someone is looking for info on how to resolve this issue and has fallen across this journal posting, hopefully this will help:

DISCLAIMER: Normal 'disclaimery' things all apply; this information is provided "as is;" if something breaks as a consequence of using the information provided, then THAT'S NOTHING TO DO WITH ME... so make sure that you understand what you are doing (I have tried to explain the bits I think aren't self-apparent, but still...). As a simple rule of thumb, you should NEVER blindly copy any procedure from an Internet source (no matter how reputable).


Note: This procedure modifies the operating state of a system Service related to the NI MultiSim product that is demonstrating excessive CPU use when the MultiSim product is not in use.

While some basic testing has been undertaken to see that MultiSim will still load and perform basic operations, using MultiSim long-term with the Service in this condition has not been tested, however a reasonable working process is described at the end of the procedure that will ensure that all Services related to MultiSim are operating when MultiSim is in use.


Note: You will need Administrative powers to do this... if you don't have them for the computer in question, you need to find someone who does!

  1. Open Windows Task Manager by right-clicking the taskbar and choosing 'Task Manager'/'Start Task Manager' from the menu'. On Windows 8 and above, you (may be) required to go through a UAC Prompt to start Task Manager
  2. On Windows 8 and above, you may have to click 'More Details' in Task Manager to see the 'tabbed' Task Manager interface and see all your system's processes.
    On Windows 7 or earlier, you must click the 'Show processes from all users' button so that you can see every process on your system. On Windows 7 or Vista, this (may) require you to go through a UAC Prompt
  3. On Windows 8 and above, go to the 'Details' tab
    On Windows 7 and earlier, go to the 'Processes' tab.
  4. Click the 'CPU' column until it appears with a 'pointing down' triangle in it; this sorts the list with the most active processes at the top of the list
  5. Identify the miscreant process... it should be at/near the top of the list now.
    As mentioned earlier, many of the MultiSim processes are named NI*something*.exe, but there are a few others (like my misbehaving ApplicationWebServer.exe process, SystemWebServer.exe and various LKsomething.exe processes) that don't.
    Note: Just because a process happens to have a name that matches these crude metrics, DO NOT just assume it is related to MultiSim; doing so could completely wreck your Windows installation.
  6. Right-click the suspect process and choose 'Properties'; the program's name, installation location and a description are given on the 'General' tab of the Properties dialog.
    Many of the MultiSim processes install under C:\Program Files\National Instruments or C:\Program Files (x86)\National Instruments, but a few do install under C:\Windows (either in system32 or SysWow64, depending on if you're running 32- or 64-bit Windows)... be careful with the ones in C:\Windows... but if you switch to the 'Details' and/or 'Digital Signatures' tabs of the Properties dialog; for MultiSim-related processes, you should be able to else "National Instruments" in the tab content
  7. Make a point of checking the 'Description' column of Task Manager for your errant process; this may be very useful later
  8. Now we know what the naughty process (and are pretty sure that it is, indeed, related to MultiSim), we can stop it and prevent it from auto-starting; press Win+R on the keyboard (ie, hold the 'Windows'/'flag' key down, tap the 'R' key, then release the key you're holding down) and type into the Run dialog that has appeared:


    then click the OK button
    If the 'Run' dialog doesn't appear for you, it may be disabled on your computer; but (for Vista and later) you should be able to type services.msc into the Start menu/screen search field and start the Services window that way... On XP, there should be a Services item in Control Panel > Administrative Tools.
    On Vista and newer, you (may) have to go through a UAC Prompt to start Services.
  9. In the Services window that opens, scroll down the list, looking at the Name column... because we know that we are only interested in MultiSim-related Services, you can jump to the one's whose name begin with "NI".
    If your runaway process is (like mine) ApplicationWebServer.exe, you are looking for "NI Application Web Server"...
    If its something else, you may be able to make an educated guess (the process name and 'Description' details we looked at previously may help with this) but if you do, you need to verify your guess.... and some of the processes (such as the "NI Time Synchronization" service, have names and Descriptions like "lktsrv.exe"), that are almost unguessable...!
    To check a Service, right-click its entry in the Services list and go into 'Properties...'. On the 'General' tab, the entry of interest is labelled "Path to executable"...
    Note: Even though this just looks like a line of text, its actually a sneaky 'stealthed' textfield, so if it seems to be chopped short you can use a mouse drag just as if you were trying to select the text in a normal textfield... and when you drag beyond the visible text, the field will scroll to the right, selecting (it looks like its highlighted) its content as it goes... this can be a little tricky to get right (it can scroll very quickly), so *hint* if you are struggling to see some of the line, but it is highlighted, you can right-click the highlighted (selected) text and choose 'Copy' and then you can paste the text into, say, Notepad for an easier look!
    Unfortunately, all the C:\Program Files.... paths are too long to see the whatever.exe part without using this select-to-scroll trick, sorry... :-(
    Anyway, if your first attempt to locate the relevant Service was unsuccessful, you just have to close the Properties dialog and keep looking through the "NI" Services until you find the right one.... its annoying, I know, but there are only twelve to check... and it doesn't really take very long once you get going, promise!
  10. So, once you've located the Service that is stealing all your CPU cycles, what do you do...?
    Well, two things:
    • The first thing is to prevent the Service from auto-starting...
      On the 'General' tab of your errant Service's Properties page, there is a 'Startup type' field; we want to change this from 'Automatic' to 'Manual' and then click the 'Apply' button. Do NOT be tempted to set this to 'Disabled' (I'll explain why at the end)
    • The second thing is to stop the process that is currently running; again we're on the 'General' tab of the errant Service's Properties page; click the 'Stop' button. Windows will say it is "attempting to stop" the Service.
      Unfortunately, for a runaway Service process, this will, in all likelihood, eventually tell you that it failed to do so with a message such as "Windows could not stop the service on Local Computer." it will probably also mention something about the Service not responding in a timely fashion.
      So what do we do to get rid of that pesky process?
      Well, we don't want to reboot; while that would be effective, it really would be overkill (but if all else fails, it is the last resort)....
      So instead, we go back to Task Manager... and (now that we've taken steps to prevent a re-occurrence), we can select the errant process from the list on the 'Process' tab and click the 'End Process' button.
      Task Manager will query to make sure you really want to end a process, to which we can now confirm that we do.... so click the 'End Process' button on the query dialog box, and after a moment (or three), the process should disappear from the list.

And there we are; the errant process has been tamed!

But I did say I'd explain why you shouldn't choose to set the Service's startup type to 'Disabled'... so I'd best cover that too....

It boils down to this; we are forcing one of the Services MultiSim may be expecting to use to not be available to it, and this could break MultiSim in unforeseen and subtle (or not so subtle) ways.

We therefore need a way to ensure MultiSim can find all the Services it expects to be available to it...and the least difficult, least intrusive way to achieve this is to simply manually start the errant process before we start MultiSim, and to manually stop it when we are no longer using MultiSim... and it isn't possible to start a 'Disabled' Service.

This "safe" working process for MultiSim is a little cumbersome, but it will work... and if you are using MultiSim occasionally, it will avoid a lot of wear-and-tear on your computer's cooling system, etc.

All we are going to do is a few of the steps we did previously;

  1. Open the Services window by entering services.msc in the Run dialog or Start menu/screen search field (or on Windows XP, by starting Services from Administrative Tools).
  2. Locate the naughty process in the Service list and start it manually (right-click it and choose 'Start')
  3. Start any other "NI" service whose 'Startup type' is 'Automatic' but whose Status is not 'Started'; these are most likely dependent on the naughty Service, so can't start themselves when Windows asks them to.
    If you are not concerned that someone may have access to your computer when your back is turned (or you nip to the loo...), you can save a few keystrokes and clicks and leave the Services window open... or you can close it, until you need it again
  4. Use MultiSim
  5. Once you're done in MultiSim, go back into Services and stop the naughty process (confirming you wish to proceed if you are prompted about stopping additional Services; those are the dependencies).
  6. Remember from before that stopping the runaway Service this way will quite probably fail; if it does, use Task Manager to "End Process," as detailed in the main procedure.

And thats it!

Hopefully if this issue does affect a reasonable number of people, a subsequent software update will fix the errant process... so if you are using this 'safe' procedure then hopefully one day soon, you'll be running MultiSim and you'll notice that your fan isn't running as much and/or the CPU isn't being overused by the naughty process...

Note: One last thing occurs to me; it is possible that an NI update may undo the change you made to the Service startup type while leaving the 'runaway' issue unfixed; if you notice the process has started misbehaving again, this is most likely why... if this does happen, all you need to do is change the Service's startup type back to 'Manual'.

NOTE: There is a further post following up on this issue here.

Edited: Added the summary and 'jump' link prequel section

Edited: 18th July, 2015 at 8:25 PM: Added links to the follow-up post

NUCcy Numptiness!!

So it turns out that you have to be quite careful setting the "OS" value in the Atomic NUC's BIOS.... I've been trying for a couple of days to get Windows Server 2012 R2 to install cleanly with Device Manager not showing any issues with any devices, but despite installing the whole Intel driver pack, I'm still seeing lots of Unknown Devices, whose PCI IDs indicate I've just installed the drivers for...!

Eventually, after much fruitless hunting around on Google for Atomic NUC-related device problems in Windows 8+ (when I was really starting to believe I was going to have to try and return as DOA a device I'd bought more than 6 months ago), it occurred to me to have a looksee if some setting in the BIOS could be disabling the "bad" devices... and when I was looking through the BIOS pages, I noticed that the "OS" value was set to "Linux" (presumably I set this when I test booted Mint from a USB stick, many months ago)... changing it to "Windows 8" and (for cleanliness' sake) reinstalling the OS and drivers and "!poof! hey presto!" one working NUC with no device issues!

I don't even want to try and guess what using the "Windows 7" setting will do... I mean, I could understand a "Windows XP" settings, that would skip the EFI stuff and make like a traditional BIOS.... -!lightbulb!- ohhhh.... I bet its to do with SecureBoot or something else UEFI-y thats pretty new and wasn't supported in Windows 7....

I thiiiink I'm going have to try to remember to avoid booting Linux with the "OS" set to "Windows 8" though...!

I've never known a BIOS "OS" value have such a massive impact on the system.... it always used to just tweak some hard disk parameters and little stuff like that.... its really weird having a BIOS settings that can screw device detection and installation so completely and utterly..... I mean, I know I've not had much exposure to the weird and wonderful world of modern hardware with its UEFI, SecureBoot, TPM, etc, etc, but still, reeeeeeeally...?!?!?!

Windows Server Licensing..... :-/

This is just a note-to-self, but if its useful to others, thats cool.

When you first start trying to work out what these licenses allow you to do, its all a bit complicated and overwhelming (partly cos there's a lot of confused "information" out there because the licensing and SKUs changed quite drastically).

As far as I can work it out, it boils down to this;

  • Standard and DataCenter are the same in terms of what is "in the box"
  • The difference between the two Editions is the number of virtual instances you can run on the licensed Server
  • Licences apply to a specific physical system
  • The number of licenses you may need is governed both by the number of physical CPUs (not cores or hyperthreaded psuedo-cores) in the system and by the number of virtual instances you are going to be running concurrently on that system
  • For physical CPUs, a single license of either Edition covers up to 2 physical CPUs
  • Multiple licences can be applied cumulatively to a single system
  • If you have system with more than two CPU sockets populated you can add additional licence(s) for the extra CPUs:
    • Divide the number of CPUs installed by 2 to get the number of licenses required for a system (and round up)
    • A 3-way SMP system would need 2 licenses (2 x 2 CPUs to cover up to 4 physical CPUs)
    • If you have one 3-core CPU, you only need one license to cover the one physical CPU. This is still true if the CPU features hyperthreading and thus presents 6 psudeo-cores
  • There is an absolute limit to the number of physical CPUs that can be licensed
    • This is either 320 CPUs or 320 licenses (for 640 CPUs)... I don't think I'm ever going to run into this limit though!
  • With regards to virtualisation, one Standard license lets you have two OS instances running on the licensed system, while one DataCenter license lets you have unlimited OS instances
    • It is worth noting that there is a point where cumulative Standard licences become less cost-effective than a single DataCenter licence. Under US pricing at Server 2012 launch, this was around 5 Standard licences (for 10 VMs)
  • There is a caveat with regards to virtualisation and Standard Edition; a Standard Edition machine that is running virtualisation software (whether it is Hyper-V or some other product, such as VirtualBox) may have two virtualised Standard Edition instances running as well as the 'host' (bare metal) instance that is running that virtualisation software but only if the 'host' instance is only running the virtualisation software and the tools and services required to operate and manage it:
    • Things like multipath I/O and iSCSI can legitimately be used if they are required in order to manage and/or run the virtualised instances
    • If the bare metal instance hosts a general purpose file Share (for example), then it is in breach of licensing
  • Hyper-V Replicas count as distinct VMs
  • Clusters require each host to be licensed for its full compliment of CPUs and for every VM in the cluster
  • Licences do not migrate with a VM, the migrated-to system must have a licence available to run the migrated VM
  • Licenses cannot be split
    • a Standard licence doesn't allow two single-CPU systems to run one instances of Server each; the licensed CPUs must be in the same system
    • one Standard licence cannot be used to licence one virtualised instance on each of two different systems
  • For 'blade'-type systems, each individual blade counts as a system that requires licensing
  • Non-OEM licences may allow for reusing a licence in the event of a hardware failure, but check the EULA
  • Software Assurance does a few magic things, like granting downgrade rights and licensing Replicas
  • Volume Licensing also has some magic regarding licence transferability... but I can't remember what and I can't find the page I read about it on

A key term to note is "running instance;" according to this Microsoft document (which is specifically linked to from the Windows Server 2012 R2 Licensing Datasheet), "Use terms for each software license specify the number of instances of software that you may run on a particular server at a time, rather than the number of copies of the software that you may install and use on your server" [emboldening added for emphasis], so it appears that with Standard Edition, you can actually have more than the 2 virtual instances set up, just so long as you never, ever, ever simultaneously run more than the 2 instances the license entitles you to run... BUT having read a few articles, it is clear that even Microsoft's own writers (and presumably their writer's technical- and proof-readers) don't fully understand their own licensing scheme, so while this is published licensing information, it may not actually be what the Microsoft Legal Department think the licensing means!

Niccy, NUCcy, Nuuu...!

OK, sooo.... a very long time ago, back when I was on placement for Uni, I picked up a license for NT4 Server and started running it on one of my machines at home (my 486 DX4/120 to be precise). This machine was set up as a Domain Controller and also ran FirstClass Server on a 5-user-or-less freebie license. This meant I had an NT system I could poke around in that wouldn't stop our users from doing anything if I broke it, while also giving me a development box for working on application code for FirstClass.

That machine was one of three that I had at that time, the others were a general purpose Windows 9x system and a Linux box that was used both as a desktop machine and as my fileserver-slash-"server-of-many-purposes"... Oh, and the fourth of my three machines was a somewhat battered PowerBook 540c from work.

This little network was my playground for learning stuff and doing things that I'd never be allowed to in a live, production environment... as a consequence, over the years it developed a few, erm, quirks.

Anyway, later on, after I'd hand-me-downed my upgraded Linux system's former hardware to replace the 486, I acquired a Windows 2000 Server licence and upgraded the Domain to a somewhat quirky Active Directory setup... this particular bit of quirkiness being down to my using 'bind' on the Linux box to host the DNS component of Active Directory, rather than the Microsoft DNS Service as most installations probably do... I wanted to try out this particular corner-case, becauseI figured there would be places that has already had DNS and didn't want to be replacing bind boxes.... and afterall, this was kind of the whole point of this little playground LAN....

Later still, when I had an MSDN subscription, I upgraded the domain from Server 2000 to Server 2003. By this time, I had a couple of Windows laptops, so most of the day-to-day desktoppy stuff was done on those.... but I still had a reasonably decent soundcard, in the form of a SoundBlaster Live, coupled with the nice Live Drive module that gave me MIDI ports and audio sockets on the front of the machine so I could use them with my synth... but I wanted to have a backup DC, as I'd had the DC go !POP! and (with no tape drive, and nowhere with enough free space to make backups to) had to rebuild the Domain from scratch, and didn't want to have to repeat that process.... in one way, that DC loss did do me a favour; I'd had Exchange Server installed at one point, which makes a lot of changes in Active Directory, but it never quite worked properly, it was like some part of the installation hadn't quite completed correctly, but not amount of clean-box reinstalling seemed to sort it... it was always very flaky... in the end I gave up on it, but that none of the Active Directory modifications got undone, so I had an Exchange-ified ADS that was missing Exchange... the 'pop' eliminated the Exchange-ification completely and in a fraction of a second! (NOT the recommended way to fix AD, I know....!)

By the time I was really properly nestified in my lovely little cottage, I was running three servers 24/7; my Linux "server-of-many-purposes", my MDC/FirstClass system and the (ex-Exchange, replacement-for-the-one-that-popped) backup DC come MIDI host/audio amplifier... and by now, things had gotten rather more convoluted... for example, I had 2 parallel printers (one colour bubblejet, the other mono laserjet), the laser printer was hooked up to the MDC/FC box, the bubblejet to the BDC/'desktop'... but because the MDC/FC machine was running Services For Macintosh (because I've always assumed (based on that being how it was on the server at work, where I first encountered FC) that because FC supports (?supported?) connections over classic AppleTalk-over-Ethernet, Services for Macintosh needed to be installed to provide the AppleTalk portion of the network stack, and also so I had somewhere to store Mac software for the PowerBook and a way to print from it), the main print spools were on the MDC/FC... but in order to print to either printer, the Linux machine had to be powered up, because AD comes in to play, and AD needs DNS to function....! And printing to the bubblejet from the 540c meant all three machines were required...!

Anyway, as I say, I was in my cottage and since I was paying the bills, I was happy enough for it to just keep going as it was...

But then I had to move back to the P'rentalles.... at which point, I thought I had better reduce the power usage somewhat, since I was no longer paying the bill.... and it quickly became apparent that this 'interconnectedness' (read 'interdepennce') just couldn't continue....

It took a little while to unravel things, but I did get things so that everything to do with the AD was on the two Windows Servers, and things like printing didn't require additional machines to be powered up... well, sort of.... my mum's bubblejet is USB, so her machine has to be on in order to print to that, and my parent's laserjet has a little Edimax printserver attached to it, but its nothing like the palaver it was.

I have maintained the Active Directory Domain (even if its still running on Server 2003 R2 in 2015...), because -shrug- I've been running it for so long now, and even if I don't use it for very much, and I don't have things like Group Policy doing very much... I guess it would be really strange to not have it, and I can't bring myself to knock it on the head... oh, that and its really nice not having to change password on all my Windows machines (6 of them, but 2 of them are only used intermittently, and I would definitely forget to change them at some point and have absolutely no clue about what the unchanged password could be!).

So I've always been on the lookout for some way to resurrect the "always on" Domain, but in a form with massively reduced power requirements, because there are some aspects of the "always on" scenario (most notably local DNS services) that I still (after a good few years) haven't gotten used to not having.

And finally the technology has become available (at a low enough price) for my to actually reinstate "always on"-ness, in the form of the Atom-based Intel NUC DE3815.

This little beastie comes in two forms, a 4"x4" bare board and a 'kit', which additionally supplies a wall-wart PSU and an enclosure large enough to hold both the board and a 2.5" SATA drive. The package is 64-bit and supports up to 8GiB of RAM, has an 4GiB onboard eMMC (think soldered-on SD Card), has a (single) USB 3 port, as well as two USB 2 ports (and headers for 3 more), audio, VGA and HDMI outputs and Gigabit Ethernet (plus headers for GPIO, UART and a bunch of other custom solution/embedded system-oriented stuff).

But the best bits are that:

  1. The SoC is a 5w TDP part... allowing the kit version to be fanless, so the only noise the machine makes is from the HDD (there is a motherboard header for a fan though, in case its needed)

  2. Everything is pretty low power (even down to using low-voltage (1v35) SODIMM RAM), so the power requirements are nice and low; I ballparked the power requirements for the NUC with its display power-saving, an active spinning-disk HDD and no USB devices, but an active LAN connection to under 20 watts, assuming about 85% efficiency in the PSU (its around 15 watts actual draw, depending on the RAM and HDD used)...

Add these two things together and you come up with a small, low power, low noise device that can run Windows... which sounds just like what I want :-)

So I ordered one around the time that Dad went into hospital... was around £110... plus £15 for a 2GiB stick of DDR3L (...and I don't need to but a harddrive, as I'm using a 120GB drive that has been sat on the spares pile for a while). Its been sat on my desk pretty much untouched (beyond checking it powered up and would boot Linux from USB) ever since. While its not as cute as the rest of the NUC range, I do think it not having any glossy plastic to gather fingerprints is a good thing, and both the placement of the power button and the provision of a nice little stand so it can sit on its end (ie, like a book on a bookshelf) are far better than the "I'm gonna take up 5 square inches of desk and you can't stack anything on top of me because you'll scuff me, oh and you have to press a button on my top to turn me on!" aspects of the cuter NUCs!!

I should mention at this point that, as a student, Microsoft's DreamSpark program allows(/ed) me to acquire one Windows Server 2012 R2 Standard Edition license and one Windows Server 2012 R2 DataCenter Edition license, and it is these licenses I've been planning this reworking of the Domain around.

Anyway, my mum just bought me a new UPS (as a(n unprompted) thankyou for doing all the cooking for us two since Dad went into hospital), so I'm trying to set sort out the various things that are going to be powered via it, and as the NUC is one of these, setting it up has become this week's "Thing to get done".

The plan when purchasing the NUC was that I'd migrate the Active Directory MDC part of the MDC/FC Server to the NUC, which would be running Windows Server Standard Edition (with no virtualisation) and that it would be "always on". Then, once they were released (and I could afford one, so not for a while), I would acquire a 2015 Core i3 NUC that would be more of a workhorse machine (but that wouldn't necessarily be "always on"). The i3 NUC would (thanks to dual cores, hyperthreading and a 16GiB nominal RAM capacity) comfortably run multiple virtualised systems, even if they were quite demanding. It would use DataCenter Edition (for the virtualisation licensing) and would host Windows Server VMs for a BDC (or two), an SQL Server and (possibly) my FirstClass server, as well as, say, a (probably TinyCore) Linux VM that I could connect to from offsite using SSH (port-forwarded from the router) that could then be used to tunnel VNC connections, etc through)...

However, while I was looking around for drivers and stuff, I noticed that the Atomic NUC's CPU supported VT-x and this gave me an idea; what if I ran two virtual Domain Controllers on the Atomic NUC...? I mean, its not like the current DCs ever really use huge amounts of CPU... and when they do, its when Windows Update is happening... so although the E3815 is only running at 1.46GHz, is single core, single threaded, and despite Atom CPUs being significantly slower clock-to-clock than a "proper" x86-64 CPU (ie, a similarly clocked Pentium/Celeron/Core part will do much more work in the same timespan; something like double, if I'm remembering various articles correctly), there should be enough horsepower there to service logon requests, serve up the necessary bits of data (like GPO) and to replicate the AD store, afterall, Atom-based server machines are out there, even if they are clocked significantly faster than 1.46GHz!

So that's where I'm at and what I'm now planning... hopefully in the next couple of days I can get everything installed on the NUC and then the next part of the plan comes in to play; drop the Server 2003 R2 DCs and update the Active Directory functional level to 2012 R2... eek!