Mark Minasi's Windows Networking Tech Page
Issue #75 February 2009

Document copyright 2009 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • Windows Server Classes in Philly (March) and Chicago (April), Special "Economic Meltdown" Prices
    • The Server 2008 Seminar is Now a 15-CD Audio Set, XP and Vista Seminars available on CD also
  • Tech Section
    • How I Saved the World From the F1MAN113 Worm
    • New Version of CHML Available
  • Conferences
  • Bring a Seminar to Your Site
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

This month, I want to tell you (with an somewhat embarrassed wince) a story about how I wasted a day trying to track down a nonexistent Trojan on my system, made that system unbootable in the process, fixed it, and in the process discovered a few new things about System Restore, WMI, and the Spooler service.  At minimum, it may serve as an opportunity for the rest of you folks to feel smarter, it may remind you of some preventive measures that you've been meaning to take but haven't yet, and/or it may pass along a couple of troubleshooting tips; in any case, I hope you enjoy it but first... a word from our sponsor.

Windows Server Classes in Philly (March) and Chicago (April), Special "Economic Meltdown" Prices

As you know, in the past year Microsoft has released Windows Server 2008, and even if you've not implemented it yet, we all know that Resistance Is Futile and so you'll eventually need to know how to plan to fit it (or its very close cousin 2008 R2) into your IT structure, get it rolled out, and then maintain and troubleshoot it... so why not learn now? 

Of course, you could download a small mountain of white papers (mostly written based on late betas and thus are only partially correct), and spend a few weeks testing it to discover the hundreds of changes that 2008 brings... or you could come spend a couple of days with me. In my Server 2008 Support class, I'll tell you and show you what's changed in Server — the good, the bad, the wonderful and the awful ... with a chuckle or two thrown in. Please consider joining me for the two-day Server 2008 class in Philadelphia on March 23/24 or Chicago on April 27/28.  But wait, there's more:

Some of you may know that a quarter-century ago, I was a Washington economist, so I think I can speak with a dab of authority when I say that this ain't no recession, folks, this here economic situation is a depression.  So I'm offering the Philly and Chicago classes at my special "economic meltdown" prices — 200 bucks off the price of every seat for those two sessions.  So please, come join me at one of my two favorite cities and let's get techie about Server 2008!

The Server 2008, Vista and XP Seminars Available As Audio Sets

I'll keep it short and sweet:  given the current economic conditions, I know that some of you would like to get to my 2008 seminar, but that there is no way that you will be able to convince the boss to let you travel or even leave the office anytime soon.  For you folks, I've recorded the Server 2008 class, my Vista Support class and my XP Support classes in their entirety and you can buy them on a stack of CDs for under a quarter of the price of attending the seminar.

The newest is the Server 2008 set and I want everyone to be able to afford this set, so I've priced it the same as I did our Server 2000 audio set nine years ago.  I've also posted online a free 18 minute sample from the Hyper-V coverage that I hope you'll like whether you buy the set or not.  More info at, and I hope you find it a convenient and entertaining way to get the ins and outs of 2008.  You can find out about my other audios (XP, Vista, etc) at; there are sample audio downloads for all of the class CD sets.

Tech Section

This month, a story and some update information on my chml tool.

How I Saved the World From the F1MAN113 Worm

(Want to listen to this?  Click here to download the MP3 version.  If the download's a mite slow then I ask that you please be patient, it's 45 megs and we've only got about a three megabit upload rate.) One of our Forum members has also set up a mirror site here (many thanks!)

The other day, I was in the middle of working on a newsletter explaining exactly why you want (or maybe don't want, in some special cases) to go 64-bit.  While working on that piece, I had my system download some big debugging files from a client's Web server, as the client had asked me to take a look at them.  That transfer had crashed partway through, so I opened up another browser and tried to start downloading the files again, only to get an error message to the effect that "you're only allowed one connection at a time, Minasi, and you're already downloading on another connection."

That's odd, I thought — I'm disconnected, why doesn't the distant Web server know it?  Well, I reasoned, maybe it's just taking the network on their end a bit of time to figure it out, so I gave it another 10 seconds and tried again, getting the same error.

Netstatting for Trojans

Once a few minutes had gone by with the same repeated result I started worrying, as I really needed to get that file downloaded so I could get to work, and so it was time for a bit of troubleshooting.  Firing up an elevated command prompt, I tried a netstat -ao command with the intention of trying to find out if I did indeed already have a TCP connection somewhere with the client's Web server. 

As many of you know, that netstat command (and the similar netstat -ano command) lists all of your current TCP/IP connections, as well as listing the TCP ports that your system is listening on.  For example, here's an excerpt from the system that I'm working on now:

C:\Windows\system32>netstat -ao

Active Connections

Proto 	Local Address 		Foreign Address 	State 		PID
TCP 		MarkT61P:0 		LISTENING 	444
TCP 		MarkT61P:0 		LISTENING 	4
TCP 		MarkT61P:0 		LISTENING 	4
TCP 		MarkT61P:0 		LISTENING 	2648
TCP 	MarkT61P:49159 		ESTABLISHED 	1664
TCP 	MarkT61P:27015 		ESTABLISHED 	3928

The first four lines show TCP ports that this system — my laptop computer, named MarkT61P — has open and is listening on, ports wherein my laptop is willing to act as a server.  The addresses all start off with, which in this case basically means "this computer."  The connections are in the "LISTENING" state which means, as their name suggests, they're just waiting for a request directed to whatever port is specified after the colon under "Local Address."  The numbers after the colons are the port numbers that it listens on, and sometimes that can be useful information if you're trying to smoke out a problem — but don't panic if you see a port that you don't recognize.  Thus, you can see from the first four lines that my computer is ready and willing to act as a server on ports 135, 445, 5357 and 6060 but has no takers on any of those ports at the moment. 

The next two, the ones in the "ESTABLISHED" state, describe currently working connections where someone's talking to my computer.  In this case, "" also means "my computer," and, again, the numbers after the colons show where my computer isn't just willing to listen, they are the numbers of the ports that it is currently actively receiving requests from clients on.  The first line means that my computer is receiving requests on port 27015 (the "Local Address") from itself on port 49159 (the "Foreign Address" reference to "MarkT61P:49159").  Thus, we not only know that my PC's willing and able to receive requests of some sort on port 27015, but that in addition it's actually active on that port.  The line after it shows that my PC's also willing to receive traffic on port 49159 and is actively receiving traffic from itself, this time with the traffic coming from port 27015.  Strange-looking, eh?  We'll see what it's really doing in a minute.

The last two lines of TCP connections that I have, connections wherein my computer is the client and some distant system.  In those lines, the "Foreign Address" is the server's address and incoming port.  Those two addresses end with ":http," so we know that they're Web traffic. 

By the way, I won't keep you in suspense — I did not see another HTTP link to the client's server in netstat and within minutes I could return to downloading the files from their site with a different computer, so the problem must have been rooted in some recalcitrant part of the client's network.  I was curious at this point about just what my computer was acting as a server for, partly because I'd been having a sneaking suspicion that my network performance was under par anyway, which led me to do the snooping that led to the rest of this story — and so we return to the netstat output.

Looking at the lines that describe server behavior, we seek to figure out what kind of traffic's running on each port, and what process on my computer opened that port, anyway?  Well, we can answer the second question with the "PID" column.  (You only get the PID column if you include the "o" — "owner" option, and that option only works on XP and later computers.)  Either using the tasklist command-line tool or by adding the "PID" (which, by the way, is short for "process ID") column to Task Manager, you can connect a port with the process that opened it.  (If you're using Task Manager, don't forget to "show processes for all users.")  I'm more of a command-line fan, though, and so I like tasklist. To put it to work, open up an elevated command prompt and type

tasklist | find " number "

And be sure to (1) put a space on either side of the number and (2) actually put those quotes around the number.  Thus, if I was wondering what the heck was running on port 27015, I'd search on the PID on its line, 1664, like so:

C:\>tasklist | find " 1664 "
AppleMobileDeviceService. 1664 Services 0 4,628 K

And now I know that it's iTunes who's squatting on my port 27015.  Analyzing these eight example entries, I see that

  • Port 135 has been opened by PID 444, which a svchost.exe.  Svchost.exe — you'll see several of them on your system — is nothing more than a container for one or more services. Clicking the "Services" tab in Vista shows me that PID 444's associated with "RPCss," which is the Remote Procedure Call process.  That's perfectly normal and in fact any Windows system without RPCss on port 135 would be quite unusual!
  • Ports 445 and 5357 were both opened by PID 4, which (at least on my system) always turns out to be the basic, central part of the operating system itself, the "kernel."  So what are those ports doing?  Well, 445 is one of the handful of ports that are worth knowing off the top of your head — it's used by the file server service.  You'll also see port 139 opened by that same file server service — the original ancient file server service, the so-called "SMB" protocol.  Although SMB runs on port 139, when Microsoft wrote up the protocol as a draft for an official Internet RFC-ed version of SMB, they renamed it the Common Internet File System (CIFS) and for reasons I've never quite grasped, defined it as running on port 445.  Honestly, that seems to be about the only difference between SMB and CIFS — the port number.  But what about port 5357?  Vista and later versions of Windows (and XP, if hotfixed) contain a replacement for the old broadcast-based Computer Browser service called Web Services Discovery (WSD).  When a Vista or later box wants to ask another Vista-or-later box what resources it offers, the interrogator sends that request formatted either as a SOAP HTTP message on TCP port 5357, or SOAP over HTTPS on port 5358.  (I already knew that, but if I hadn't, then Googling "Windows tcp port 5357" would have brought the answer.)
  • Port 6060's an oddball,  but running Sysinternals' Process Explorer rather than Task Manager (why the heck Microsoft doesn't just throw away Task Manager and replace it with Process Explorer is beyond me) offered a clue: "Lenovo Client Security Solution."  Ah, so it's one of the zillions of clutterware apps added by my hardware vendor.
  • And what about port 27015?  Again, PID 1664 led me to the "Apple Mobile Device Service."  So let me get this straight, Apple:  I've got to use iTunes to control my iPhone, I specifically do not share my libraries and don't seek to share others, and you've still got to open a port on my computer?  Arrgh.  Note that the end of that line shows me that it's talking to PID 4964, "iTunesHelper.exe," which is listening on port 49159.  Ah... I see; iTunes has installed multiple applications on my system, and they talk to one another over TCP/IP connections rather than some internal inter-process communication. 
  • Again, those last two entries show that my computer — its address is — is acting not as a server this time, but as a client, with two HTTP connections to two servers whose addresses start with "65.55.11" and, as I was connected to Microsoft's site as I ran that command, it'll be no surprise that those are IP addresses in Microsoft's range.

If poking around Task Manager for PIDs or typing tasklist commands doesn't appeal to you, then you might like a freeware tool called CurrPorts from a fellow named Nir Sofer.  It opens a Task Manager-like window that shows all currently-open ports and who's opened them as well as some information about the connections and processes.  (If you run it from Vista or later systems, run it elevated or it can't show you a lot of the information.)  You can find his app at and it's worth a look.

Analyzing my netstat output — which was of course much larger than the little snippet that I presented above — and looking for a stray TCP connection reminded me how large the volume of persistent TCP traffic a normal system maintains, and how much of that is perfectly legitimate HTTP traffic.  In my case, I access my non-Exchange email server via HTTPmail, run Wunderground's Vista Sidebar gadget, and keep open a local Web page from an NOAA weather instrument package.  But it doesn't end there, as Windows Update, Adobe Updater, and all of the other updaters are all pretty chatty as well, making identifying any suspicious traffic difficult.  Fortunately, however, I did do something right, as I saved a screenshot from a netstat that I did after getting my system up and running, so all I had to do was compare the current netstat output to the saved output from nine months ago.

So there's a first moral for our story:  keep and maintain baseline pictures of your network traffic and running processes so it's easier to spot something unusual later.

Sniffing for Trojans

After working through my netstat output, I accounted for all traffic... but what if some rootkit were blocking netstat from telling me the whole story, what if that rootkit had "stealthed" its communications?  In that case, there's another, more objective way to gather clues about my system's TCP traffic:  to sniff its network activity from another system.  Sniffing switched networks usually yields little information, so I attached a hub to my network and then connected my laptop and another system to that hub and fired up Network Monitor 3.2 (a free download from Microsoft) on the other system, setting the network capture to "P-mode." P-Mode is Netmon's phrase for "promiscuous mode."  That's useful because by default Netmon (and all other network monitoring software that I know of) monitors only broadcasts and traffic specifically directed to and from the particular computer that's running Netmon — they don't report on any communications that they overhear between other systems.  Network monitoring software running in promiscuous mode, in contrast, reports all traffic that its system hears, whether it's specifically directed at or from that system or not — sort of like having some nosy person listen in on a party line 24x7.  As the extra system was on the same segment as my laptop, any network traces run on that system would overhear and report on any traffic to or from my laptop.

What was I looking for?  Well, something — or anything — strange-looking emanating from my laptop.  Things like IRC communication, piles of SMTP traffic, or perhaps a periodic communication with some system out on the Internet, such as you'd see a member of a "bot army" do.   And that's why I first glimpsed my first evidence yes, something sneaky appeared to be happening.  Minutes after booting, my computer started doing a NetBIOS name resolution broadcast requesting a system named "F1MAN113."  It did it, again and again. 

Uh oh, I thought.  I've never had a domain, workgroup, share, or server with that name.  So why would my computer be looking for something with that name unless it had been... eek... compromised?  (I should parenthetically note that I'm neurotically careful about where I surf, what I download and what I run from the Internet; whenever something looks even vaguely worrisome, I fire up a VM, download it to the VM, extract it and run a malware scan (or two or three) on the file.  But, as I say, I'm paranoid.  Additionally, I'm even more paranoid about finding one day that one of my systems is either part of a bot army or runs some malware that's trying to spread the worm du jour... I would really hate to be one of the bad guys, even if inadvertently.)

Moral #2, then, is:  Always keep a hub and a copy of NetMon or Wireshark (an open source network sniffer app) nearby so you can use it to spy on the network conversation of a system that you suspect of having been compromised.  But please, do not do this in your corporate network without first talking to your security guys, as being caught sniffing your company's network traffic can get you fired in many places.

At this point, I Googled "F1MAN113," expecting to find Web pages about its associated worm and what to do about it.  What did I find?  Nothing... which was even creepier.  Could it be that I was the first victim of some new worm?  Was I the "zero" in "zero day exploit?"

Rooting for Trojans

Time for a rootkit check, I thought.  Of course, the tough part about finding a rootkit — that is, a piece of malware that modifies the operating system so that the operating system shows no traces of the malware's existence — is that, well, rootkits hide themselves from the operating system, and so running something on the computer that detects a rootkit is sorta hard.  The idea in writing a rootkit detector, then, is in discovering and exploiting some imperfection in the rootkit's cloak.  (As geeks my age can attest, even the Romulan Cloaking Device had a flaw — you couldn't fire weapons while cloaked.)  Unfortunately, however, I don't know of any off-the-shelf rootkit detection apps that work on a 64-bit platform, and I'm running 64-bit Vista, so I'm on my own.  (And, as you'll read in that 64-bit newsletter when I get it done, it's really hard to implant a rootkit in 64-bit Windows.)  Fortunately for my efforts to smoke out a suspected rootkit, however, I have WinPE.

WinPE, as you know if you're read Newsletter #59, is Vista with the GUI, Control Panel, and lots of other stuff deleted, resulting in an OS that's not terribly useful as a productivity platform but just dandy as a troubleshooting platform, so long as you're not afraid of command-line tools.  As it's small, it fits on a USB stick, or a CD-ROM.  By cold-booting my laptop with a WinPE CD, I was able to examine my laptop's hard disk without having to activate the laptop's OS, thus foiling any supposed rootkits — after all, if the infected OS isn't loaded, the rootkit isn't loaded, and so no stealthing's happening.  I don't yet know of any mass-market rootkit scanners that can run or have been made to run under WinPE, so I settled for looking at the file dates and sizes of ntoskrnl.exe, hal.dll and bootmgr.  When they checked out okay, I started up Regedit and looked in the various keys that contain lists of things to run, like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, the nearby RunOnce key, their siblings in HKEY_CURRENT_USER and others — I know those first four by heart, but to get the others I just start up a copy of Sysinternals' AutoRuns and look in the keys that it lists.  Nothing suspicious appeared to be anywhere in there, so I rebooted... and discovered my next clue.

As rebooted the laptop, I was briefly called away.  When I returned a few minutes later, I looked at my other computer — which was still running Network Monitor — and noticed that my laptop hadn't yet tried to resolve F1M113 since rebooting.  I hadn't had the chance to log onto my laptop yet, so I did... and the broadcasts began immediately.  Aha... so this behavior only happens when I log on, so whatever starts it probably lives in my user profile.  That seemed to me to cinch the notion that whatever was causing this odd behavior wasn't a rootkit, because what would be the point in building a rootkit that's inactive until a user logs in?  Just to test the theory, I created a second local user on the laptop, rebooted and logged in as the second user... no broadcasts.

System Restore:  A Solution Worse Than the Problem (In This Case)

Not sure where to go from there, I decided to try rolling back my system with System Restore to see how long I'd been looking for this F1M113 thing.  Using System Restore, I rolled my system back to mid-January... and unfortunately the broadcasts still happened.  Time for a search, I guess, so I searched every file and folder on the C: drive for the string "F1M113" and was delighted to get one... a folder named C:\Windows\System32\spool\SERVERS\f1man113.  "Hmmm,", I thought.  "So it's Spooler-related!" 


Well, that would explain why it only starts up when I log in, if... open up the Printers folder, and there's an entry in there named "Speaker Printer on F1MAN113."  Yup, back in November I attended a conference and needed to print something, so I went to the speaker lounge and followed the instructions to attach to the printer in that room... and I guess my system's been missing that printer for ages.  Ah well, false alarm, looked for a Trojan and couldn't even find a Greek (or a geek who's a hacker, for that matter).  Troubles are over; ... or so I thought.

Moral #3:  I need to be better about keeping a change log on my laptop.  I'm pretty religious about it on my servers but clearly I need to do more of it for my laptop.

Realizing that the System Restore rollback that I'd just done was unnecessary, I thought I'd just tell System Restore to restore me to the place where I'd left off; with System Restore, I'd gone from 5 February to 15 January, and System Restore advertises that it can un-SR back to a previous point — i.e., 5 February, and I've done it in the past — with XP — so I know that it works.  So I System Restore-d back to 5 February, rebooted, and was informed that Windows couldn't reboot because of some very simple driver (I think it was the mouse/keyboard one).

Oh, crap.

At this point, I should add Moral #4, which is:  okay, I wasn't really that freaked out.  If you're running Vista, for heaven's sake invest in an external eSATA drive ($130 for a terabyte) and do CompletePC Backup as often as you can.  I did and I do a CompletePC backup every week, which meant that if all else failed I could always wipe and rebuild in about two hours and lose only a few days' work.  Believe me, there's a difference between "oh, crap," and "OH MY GOD WHAT THE HECK AM I GONNA DO NOW??????."<g>

This was actually interesting, as I've used System Restore on XP and Vista a number of times and generally consider it to be a great tool, inasmuch as pre-XP I would wipe and rebuild my desktop on a regular basis because, well, experience had taught me that you had to, and many people agreed, but, in my experience System Restore changed that for me.  I never had to rebuild the 32-bit XP system that I used for three years, my 64-bit XP system I used for 18 months, and the 64-bit Vista system that I've used for almost two years.  Some readers, however, had written me, telling me that System Restore had let them down, and I had no doubt that they knew what they were doing and wanted to help, but couldn't reproduce the problem... until now.  My system wouldn't boot, and so the next logical step was to boot from a Vista installation DVD and, when it said, "Install Now," choose instead "Repair Your Computer."  You then get a wizard that tries to detect whether or not you've already got Vista on your hard disk and, if you do, whether or not it needs its startup information fixed.  This detected that I did indeed need help, offered to fix it, and rebooted... only to report that another very basic driver was troubled.  This led me — and reminds me — of the next moral:

Moral #5:  It's far easier to do a boot-from-the-install-disk-and-repair-things operation if you have a boot disk with the latest version of the operating system, service packs included.  I was at a remote location, and did not.

I didn't have a Vista SP1 install DVD, so I was working from what I did have, which was a Vista RTM install DVD, and clearly it wasn't going to help (to no surprise).  So I downloaded the 3+ GB ISO image of the Vista install DVD with SP1 integrated, burned it to DVD and tried Startup Repair from there — it fixed one driver and then complained that another needed fixing.  At this point I thought that hey, I knew what those readers had been talking about, as System Restore and the "Startup Repair" tool seemed to be failing me.  But I had a little time to waste — I was working on a different computer doing that work for the client with my finally-downloaded files — and so I humored it and let it "Repair my Startup" again and again.

Now, it took about five minutes for the system to boot from the DVD, so I'd acquired something of a rhythm — "let the Startup Repair tool work, wait for it to reboot and fail again as I turn around and work on the functioning system on the client job for a bit, then turn around and see the boot failure" — and so I was downright cold-cocked when I turned around... and found that the system booted just fine.  Sure, it'd taken four repairs, but the job was done and the computer booted.  Which leads to...

Moral #6:  Don't give up on Startup Repair — give it a few tries before deciding that the patient's dead.

System Restore's Last Gasp?

Once I had the system up and running again, I thought it might be a good idea to create a System Restore point, so I tried... but System Restore failed with an obscure error message.  Okay then, I thought; let's try a CompletePC backup.  Perhaps because I activated it from a command line, I again got an error, but this one offered a bit more detail:

Failure in a Volume Shadow Copy Service operation. (0x807800A1)

Additional Information:
The writer experienced a transient error. If the backup process is retried, the error 
may not reoccur. (0x800423F3)

A bit of searching the Web brought the answer.  The basic problem, as you've probably already seen, was that both System Restore and CompletePC backup rely upon volume shadow snapshots, and for some reason Volume Shadow wasn't taking any new snapshots.  The root cause of this was apparently a corrupt WMI repository — others reported that simply turning on the Volume Shadow service or turning it off and then back on was sufficient, but that didn't help in my case — and so I did this:

  1. Reboot the system in Safe Mode, not Safe Mode with Networking or Safe Mode Command Prompt.
  2. Open an elevated command prompt.
  3. Type "net stop winmgmt" to shut down the WMI service.
  4. Rename the c:\windows\system32\wbem\Repository folder to c:\windows\system32\wbem\RepositoryOld or something like that; you just want the system not to have a Repository folder.
  5. Next, have the system rebuild a fresh WMI repository.  Start that off by restarting WMI by typing "net start winmgmt."
  6. Type "winmgmt /resetRepository." Then reboot the system to a normal startup.

At that point, System Restore and CompletePC backup worked great.  But what corrupted my WMI repository in the first place?  I still don't know, but I wonder if it was running System Restore on a Vista SP1 system from a Vista RTM DVD.  It seems odd that the Vista RTM System Restore wouldn't be able to recognize that it was working with a WMI different enough from what it recognized to endanger it, but I suppose it's possible.  Or perhaps it's just another proof of that ancient wisdom and Moral #7: "If it ain't broke, don't fix it."

Postscript 28 March 2009: A few weeks later, I upgraded my laptop's hard drive using the CompletePC Backup / swap the drive / Complete PC Restore "bare metal" restore to the new drive trick. All went well and I ended up with a system that was properly transplanted to its new, larger drive, until I tried to back up the system. CompletePC Backup would say something like "preparing the backup" for about twenty minutes and then fail. Once again, I rebooted in Safe Mode and reset the Repository, and CompletePC Backup once again started working.

New Version of CHML Available

A couple of years ago, I released chml, a command-line utility that lets you examine and change a file or folder's "windows integrity levels," a little-known change to Windows security that appeared with Vista and continues in Server 2008 and Windows 7.  Many of you have downloaded it and have had some very kind things to say about it — thanks! — but one sharp-eyed user, Peter Strelecki , noticed that under some circumstances chml couldn't figure out if the file/folder name that you fed it was a file or a folder.  That impelled me to drag out the code, give it a look and smoke out the error.  While I was in there, I added a new "-rl" option that will remove any integrity label from an object, and verified that it works under Windows 7.

Find this free tool and an explanation of how to use it at  Give it a shot and let me know how you like it!


Where Rhonda and I will be in the next few months:

Windows and Exchange Connections Orlando March 15-18

This year, the Windows Connections folks are the first out of the gate (conference-wise) with their Windows/Exchange show.  (They also do a developer-centric show the next week in the same location for the SQL, .NET, SharePoint and other crowds.)  I'll be keynoting as well as doing breakouts on "Hyper-V Without the Hype," "IPv6 for the Reluctant," and "Securing Modern Windows Systems."  Rhonda will help you head off true Active Disaster with "Failed Sysvol Replication can Wreak Havoc in your Network" and then demystifies Windows' deployment tools with "Create Your Own Unattend Answer Files for Vista and Server 2008 Using Windows System Image Manager (WSIM)" and "Windows Deployment Service (Microsoft's New RIS): Why It's Worth A Look!"

More info at  See you there!

TechEd US Los Angeles May 11-15

This year, Rhonda and I get to do the the TechEd preconference session introducing the world to Windows 7.  But that's not all:  I'll also offer a breakout session presenting an overview of the neat new Active Directory stuff in Server 2008 R2, and then I get to do three cool security talks.  First, I'll reprise my popular "12 Tips To Secure Your Network" talk, revised for 2009 realities, my new "Cracking Open Kerberos" talk, as well as "Uncovering Vista's Two Security Stars," an in-depth -- and contrarian -- look at User Account Control and Windows Integrity Levels.   Rhonda's got a bunch of sessions as well on WDS and more (we're waiting to hear the final list).

Find out more at

TechMentor Orlando June 22-26

They've asked Rhonda and me to return to the Royal Pacific Resort and I'm hoping to see some of you there!  Get more details at (the exact schedule's not up just yet but should be soon).

Microsoft's MMS April 27-May 1

Rhonda's at MMS in Vegas this year (I wasn't invited <sniff, sniff!>) doing some really cool talks:  her WDS overview and "What's New in Windows Deployment in Windows 7."  If you're going to be in Vegas and want to see how to save a boatload of money on your rollout tools then don't miss these talks!

Info at .

Rhonda in Ireland and Belgium:  March Tech Days

Rhonda's going to Ireland on 10 March and Belgium 11/12 March, then returning to Ireland on 13 March (that lucky girl).  All Microsoft-sponsored events where she'll talk about Network Monitor and deployment stuff... not to be missed!  Drop Rhonda a line at for more details.

Bring Mark to Your Site to Teach

I'm keeping busy doing Server 2008 and Vista seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2008, Vista, security, XP, Active Directory or 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, military and other organizations that I've assisted, either take a peek at the course outlines at, mail our assistant Jean Snead at, or call her at (757) 426-1431 (only between 1-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I hope that it is a useful source of Windows technical information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 45,000 subscribers and I hope to use this to get information to every one of my readers. Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at  Thanks for letting me visit with you, and take care. 

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit To change e-mail or other info, link to  To unsubscribe, link to Visit the Archives at Please do not reply to this mail; for comments, please link to

All contents copyright 2009 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.