Hyper-V hangs on "Applying changes" when adding a new drive

While attempting to add a VHD as a hard drive to a Hyper-V virtual machine, I had to wait a very long time for the "Applying changes" dialog to go away. When it did, I was greeted with a generic failure message.

When I recreated the stuff in the VHD as a VHDX, however, it worked fine, and the progress dialog went away almost immediately. This is a Generation 2 VM, so it might be more strict about what sort of things it accepts. If that is the case, I wish the UI made such limitations more obvious. If it actually has to do with the machine being Generation 2, G2 might be more trouble than it's worth for me due to this and other surprises in the past.

Hyper-V: "No boot entries"

I created a Windows 10 VM with Hyper-V today, and I noticed that its settings seemed to have no way to set a boot order. The machine was Generation 2, and no "BIOS" entry was to be found in the Hardware category. Under "Firmware", there was a message stating "No boot entries", despite a bootable ISO being in the virtual DVD drive. When I tried starting the machine, the PXE firmware appeared.

I did some Googling and was unable to turn up anything relevant. Waiting for a while, however, resulted in the VM booting from the DVD after it gave up on the network. Later, once the OS got installed, an entry did appear in the Firmware section, but is not editable. That's rather strange, and I'm not sure how to change this VM's boot order, but at least patience let it start.

Office 365 Deployment Tool

Office 2013's style of installation makes it tricky to deploy and license via normal methods. Streaming every installation package from the Internet seems inefficient to me, and Microsoft understands. Therefore, they created the Office 365 Deployment Tool. It enables you to download the installation media to local storage for simpler deployment. The Configuration.xml file governs the behavior of the tool, and the program itself has very sparse information on what you need to do, so you'll want to consult the reference.

Services that aren't

Most Windows services are normal programs run under the direction of the Service Control Manager. Some run in shared processes named svchost.exe. If you poke around with sc.exe, however, you might find some that are neither and that can't be found anywhere in the Services snap-in for MMC. The Volume Manager Driver (volmgr), for instance, cannot be found anywhere in Services or in the listing of sc query.

It will, however, appear if you use sc queryex type= driver. See, some "services" aren't programs in the normal sense. Instead, they're kernel-mode drivers (TYPE: 1 KERNEL_DRIVER) that the Service Control Manager is responsible for handling. Since they're not the same kind of thing as standard services (they have no process ID, for example), the Services control panel doesn't show them. You can, however, start and stop them with sc on the command line.

Solving the ClickSend message processing mystery

A couple days ago, I was quite baffled as to why one of my programs was not seeing input as it appeared in the ClickSend web app. Today, after perusing my log files, I think I've figured it out.

Some people's phones evidently send a line break at the end of SMS messages. My program looked for keywords in the message, but the line break after the last word made it appear as a word not in the list of keywords. Therefore, it didn't process the message correctly.

I have updated the program to replace CR/LF with spaces before searching for keywords. I will know tomorrow whether that solved the problem.

Data Recovery Agents and EFS

The Encrypting File System in Windows/NTFS is very nice, protecting user files with a key derived from the user's password. That means that if the user's password is forcibly reset (as opposed to changed), the user will lose access to EFS-encrypted files. That could be a problem.

Fortunately, Windows allows the registration of Data Recovery Agents for EFS. DRA certificates are also derived from a user's password. When an EFS file is created or touched, Windows encrypts the file's symmetric key with each DRA's public key in addition to that of the user. Therefore, even if access to one key is lost, a DRA can recover the file.

Note that EFS does not necessarily prevent malicious programs running as a user from accessing encrypted data. Malware could simply wait for the target file to be opened; it could also register a DRA certificate for a new user, wait for the user to touch some files, and read them with the DRA's account.

Intermittent problems when receiving messages through ClickSend

Now that I got ClickSend connected to a program, the program is indeed doing its job. I am, however, noticing a strange phenomenon. Sometimes, the program doesn't understand what was said by the human even though it appears correctly in the ClickSend history web control. Sadly, I can't run any debugging beyond logging on the production machine, so I can't know exactly what's happening.

The program is supposed to receive replies by polling the server for an XML document. Parsing the XML works fine, but the user data is not being handled as expected. My guesses at the moment are character encoding mismatches and the presence of extra spaces. The web control doesn't tell me how the text was encoded, though the documentation indicates that the XML document should be UTF-8. There also don't appear to be any extra spaces in the replies when viewed online, though it is conceivable that my code could misbehave when given them.