Windows 10 for Fun and Profit

I’d been having a random issue with my computer for at least the past month.   A couple times per day, a rundll.exe process would spin up and eat about 25% of my CPU.   I tried to figure out where it was coming from, but I couldn’t find with with Process Monitor or anything else.   The “image” was inaccessible when I found it in the ProcMon results.   To stop the process, I simply had to kill it from Task Manager, but that was getting old.

Today, I downloaded the Windows 10 Technical Preview to run on my primary work laptop.   This isn’t really recommended, since this is for work and all, but I mostly use Outlook, Lync and an RDP connection for everything.   Plus, I still have a VDI machine sitting in the office I can use for everything if I become desperate.

So far, after 10 minutes, it’s looking good.   I love how when you reinstall a computer, it seems so darn fast no matter what you had on it before.   This new Start Menu is nice, but I don’t have a problem with the Windows 8 Start Menu.   Cortana is neat and looks just like it does on my Windows Phone, so that’s a nice added feature.

More to come as I use it more.   Maybe this is the version of Windows that actually replaces Windows 7 all around the world.

MS Antimalware on Azure

Microsoft has made System Center Endpoint Protection a free extension for all Azure virtual machines.   This is great news for folks who just need basic AV protection on their VMs, as it’s a license they don’t have to pay for (or it’s at least “included”.)   Another kind-of-nice feature is that this add-on automatically downloads updates from download.microsoft.com and you don’t have to do anything to manage the clients.

That last part is awesome in some ways, but has drawbacks, too.   I cannot find any way to log into the GUI on the machines to configure things like exclusions, real time protection, or anything else on there.   What you can do for this, though, is to deploy the add-on using PowerShell with the command Set-AzureVMMicrosoftAntimalwareExtension and by providing a configuration file.   The config file can be either an XML or a JSON-formatted file, like the following JSON example:

{
“AntimalwareEnabled”: true,
“RealtimeProtectionEnabled”: true,
“ScheduledScanSettings”: {
“isEnabled”: true,
“day”: 1,
“time”: 120,
“scanType”: “Full”
},
“Exclusions”: {
“Extensions”: “.ext1;.ext2”,
“Paths”: “c:\\excluded-path-1;c:\\excluded-path-2”,
“Processes”: “excludedproc1.exe;excludedproc2.exe”
}
}

Having tried both XML and JSON, I found the JSON file to be easier to deal with, because the “Paths” and “Processes” are all on one line, as opposed to having separate <path> and <process> parts for each and every one.   You do need to use double backslashes in the JSON file, but that’s easy enough to deal with.

Each time you need to change this, you simply redeploy to the client(s) with the values in here you need.   I was able to use a few pages from Microsoft to figure out a “standard” exclusion list, including things for domain controllers, SQL Servers, and their standard server exclusions.   These can be found at http://support.microsoft.com/kb/822158.   Fortunately, even if the files and paths are not actually on a client, the list works anyway, as it just drops the values as DWORDs under “HKLM\Software\Microsoft\Microsoft Antimalware” in the registry.

The only other real issue with this AV solution is the lack of a central reporting tool to check on things.   You can enable some monitoring that drops log files to blob storage, but that’s really it, and it is disabled by default.   Unless your security compliance manager gets really antsy when he can’t get a report in his email everyday, though, this is probably still sufficient.   I cannot say that I’ve actually used any AV GUIs in the past 15 years anyway, as I’ve just assumed that things were going along fine until an error has popped up.

Saving the day

It’s hard to be a hero.   The girls were watching TV in the basement a few minutes ago and ran up screaming that they saw a lizard go into the bathroom.   We’ve seen one before, so this isn’t completely nuts.   I went down there with my 5-year-old, the only one brave enough to chase it, and it’s already disappeared into a wall somewhere.

I hope I don’t have to hire an exterminator to get rid of these things.   Either way, I’m the hero today!

Minor PowerShell DSC Fail

(Notice I didn’t say “fail”?  Fail is a freakin’ verb.)

I’m starting to try out PowerShell DSC so I can integrate some built-in Microsoft goodness into my Chef recipes.   Chef is pushing this as a great solution, because it gets them out of writing their own recipes for everything, plus Microsoft promises to keep the DSC portions in the OS forever, as it’s native.   This is a great idea, and I think it’s very workable together.

We are now on Wave 10 of the DSC Resource Kits, and this newest “wave” contains all kinds of nice modules.   At this point, you can basically configure everything on a Windows box using DSC.   Pretty neat, and not so hard to do when you can integrate it with something like Chef to push out the configurations.

In the xNetwork module, there is a module called xFirewall that allows you to build firewall rules in Windows firewall.   Simple enough.    Firewall rules, regardless of the vendor, have always required basically 5 configuration items:

1.  The name of your rule.
2.  The source address or range of addresses.
3.  The destination address or range of addresses.
4.  The port.
5.  The direction of the rule (inbound or outbound).

Off the top of my head, I can think of nothing more important than those 5 items.   Here’s where the xFirewall module fails.   You can easily create rules for the firewall, including Windows Firewall specific things like the application you’re allowing, the “profile” you’re putting it in, etc.   However, YOU CANNOT DECLARE THE SOURCE ADDRESS FOR THE RULE!!!!!

Looking through the DSC code, they are depending upon the “set-netfirewallrule” and “get-netfirewallrule” cmdlets to do the heavy lifting.   Set-netfirewallrule does have an option (-remoteaddress) that lets you declare the source address for the rule.   The get-netfirewallrule, though, doesn’t pull this property into the results!!!   Therefore, you could feasibly set it, but within DSC, they couldn’t do their test to see if the rule is the same as what you want to change!   Instead of fixing the get-netfirewallrule cmdlet and distributing a new version, they just left that little option out of the module.

That stinks.   I can certainly fix this on my own.  I totally see how to do it, but how much effort should I have to put into this thing?   I’ve posted on the Wave 10 download page to see if anyone can work on it.   Until then, I’ll just use the Chef windows_firewall cookbook that I’ve already made work.

Running in the Cloud

I’m starting myself a little public blog.   I’ve been doing some blogging on my company’s (Trek Bicycle) internal blog system for about a year and, while I don’t have many people reading it, it’s been nice to go back and refer to some of my posts down the road.

The goal of this public blog is to replace my one in the office, so I’ll be posting little technical tidbits I find along the way.   On top of that, since it’s personal, I’ll be jotting down some things here and there about my family and my own escapades with marathon training.

Will anyone care enough to read?   I dunno, and I really am not worried about it.  This is mostly about just having a log to go back to in 6 months, 1 year, or however long, when I know I did something but don’t remember the details.