Windows IT Pro Community Forum, October 2010

\[Editor's Note: This month's IT Community Forum presents a selection of comments and discussions from our website, duplicated here with only minor editing for style. You can take part in our community by logging on to www.windowsitpro.com.\]

Spiceworks Fan

\[The following comment is in response to Michael Dragone's "Spiceworks 4.5" review (InstantDoc ID 125235)\]

\[The current version of Spiceworks is 4.7\], which, with the use of a script available from the Spiceworks website, \[lets you\] monitor both Exchange 2007 and Exchange 2010 servers. As a Spiceworks user since 4.1, it is a great tool, worthy of 5 out of 5 once you start using it on a proper network. I have it running on two subnets at the moment, one set as a remote collector to reduce traffic between the subnets. It may be a little tricky to get set up initially, but then again, so are other network management tools, a lot of which require the installation of agents on the clients. Spiceworks has zero footprint on the clients. Your login is also used to access the Spiceworks community, a great bunch of people who can help you with a lot of problems. The community has members from all over the world, so you could think of it as a free 24/7 support desk. In the four years that Spiceworks has been in existence, there are now over 1 million members/users. I am proud to be one of them.

—Lyons

Sysprep Advice

\[The following comment is in response to Mark Minasi's Windows Power Tools column, "Creating Bootable VHDs with Disk2VHD" (InstantDoc ID 125422)\]

Mark Minasi gives us excellent advice when he instructs us to generalize the images with Sysprep. We would not want to deploy the same non-Syspreped VHD to more than one machine. For example, the computer name should be changed. But Mark writes, "Creating an image and handing identical copies of that image out to zillions of machines can cause some trouble security-wise." Trouble security-wise? Hardly any. Please refer to "The Machine SID Duplication Myth" (blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx). I quote: "This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that—with one exception—Windows never exposes a machine SID outside its computer, proving that it's okay to have systems with the same machine SID. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft's support policy will still require cloned systems to be made unique with Sysprep." Bottom line: We should Sysprep, but we should not view it as a security measure.

—Dimitrios Kalemis

Detecting a Heartbeat

\[The following comment is in response to Michael Otey's "Hyper-V Live Migration: A Step-by-Step Guide" (InstantDoc ID 125262)\]

If the servers will be clustered, you should have a private network for the cluster heartbeat. This will either be a crossover cable between two hosts in a two-host cluster or a private VLAN on the switch dedicated just to these servers and this task. \[According to Aidan Finn (www.aidanfinn.com/?p=10311)\], "There are quotes out there about Windows Server 2008 failover clusters not needing a heartbeat network. But If CSV is configured, all cluster nodes must reside on the same non-routable network. CSV (specifically for re-directed I/O) is not supported if cluster nodes reside on separate, routed networks." Good article.
—Bolton

Group Policy Pointers

\[The following discussion is in response to Harry Verge's "How to Trigger a One-Time Group Policy Registry Refresh" (InstantDoc ID 125265)\]

Interesting article. There are a couple of inaccuracies or bad assumptions here to be noted. First off, I don't typically recommend \[that folks tinker\] with the registry metadata associated with Group Policy, simply because it's not a documented, supported method. But, that aside, the author misses some key points about how Group Policy processing works. First off, the Group Policy engine has no notion of CSE versioning. This means that you really can't effectively isolate a refresh based on a particular CSE. For example, if you have a GPO (or several hundred GPOs) that contain both registry and security policy, if the Group Policy engine detects that it has to do work for either extension, then both will process, simply because it has no notion of which changed. So, you can't simply tweak the registry extension and assume that only that extension will process during the next refresh. Second, the notion of a toggle GPO is redundant. If you really want to trigger a refresh without touching every client, simply make a benign change to an existing GPO and then undo it (or use my GP-touch powershell cmdlet to increment a GPO's version number). Finally, it's a common misconception that a foreground refresh (i.e., reboot or re-logon) forces a Group Policy refresh. It does not. Group Policy will not refresh unless something has changed—period. It doesn't matter if it's a reboot or a background refresh.

—Darren Mar-Elia

I think that this article is excellent. I also think that Darren Mar-Elia's criticism may be unfounded. First of all, the author did not really touch the subject of CSE versioning. Second, the notion of a toggle GPO is not redundant. Perhaps someone may not want to make a change to an existing GPO, even if that change would be a "benign" one. Third, I did not find anywhere in the article that the author supported the incorrect idea that a foreground refresh (i.e., reboot or re-logon) forces a Group Policy refresh. Last, I would like to point out that this article has great educational value. I wholeheartedly recommended it to anyone who has learned the basics of Group Policy but still misses a few subtle but important points.

—Dimitrios Kalemis

\[My comment\] was less criticism than correction. The lack of coverage of CSE versioning was precisely my point: Without understanding that, you risk unintended consequences by thinking you are just refreshing one CSE. The point about the "toggle GPO" is a matter of perspective, I suppose. I find it more invasive to create a new GPO than to "touch" an existing one. This becomes more poignant if you start talking about CSEs other than registry. There are many ways to force the Group Policy infrastructure to think a change has occurred. In my experience, the client-based ways don't necessarily scale. The point about reboot not necessarily triggering a refresh was probably me reading into what was written here: "After you run it, the registry client-side extension will refresh the registry at the next reboot or the next Group Policy refresh." Finally, while I don't necessarily see any problem with sharing this kind of information, it provides an incomplete picture of how Group Policy processing works under the covers. \[As with\] the CSE versioning point, unless you understand the full picture, you have the potential to cause some grief in your environment. So while I think it can be educational, there are some key pieces missing.

—Darren Mar-Elia

Running as Administrator

\[The following discussion is in response to Russell Smith's "Solving User Account Problems" (InstantDoc ID 125157)\]

Great article, Russ, we are trying to edit an executable \[so that it doesn't\] pop up the UAC prompt as part of \[its\] running in the login script. I tried using \[Heaventools\] to edit the manifest and change the —AnonymousThanks for the feedback. Maybe the executable really does require administrative privileges to run? So when you force it to start as a standard user, it fails to launch or it hangs. You might try using Process Monitor from the Sysinternals tool set to investigate the problem further.—Russell SmithThanks, Russell, good article. I still have one situation I can't get around, \[and\] I was hoping you may have some ideas to help. When some machines are logged on with admin accounts I want some commands to run that are in the startup folder but they need elevated admin rights; instead of even prompting, they just fail to run, putting out a message to \[the\] command window: The requested operation requires elevation (Run as administrator). I don't think I can change the manifest for the command prompt, if one even exists. For example, one command is a Netsh run from a .cmd file. I tried creating a shortcut to it and then under Properties, Compatability tab, set the option Run this program as administrator, but this is always grayed out. Do you know of a way around this sort of issue without turning off UAC? On more than one occasion, I've wanted batch files to run that need elevated privileges and would even find it acceptable if the user was just prompted for elevation instead of commands failing and users having to manually open a command prompt with admin privileges, and then navigating to a batch file and running it. Is there a way to do any of this with \[a\] Windows 7 \[machine\] that is a domain member? Thanks.—StenbergThe easiest way around this would be to set up a Group Policy startup script to run the Netsh command. GPO startup scripts run in the context of the local machine account, which has administrative privileges. As the name suggests, however, startup scripts run once before users log on. If the Netsh command must run as users log on, the Script Elevation PowerToy (technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx) should do the trick.—Russell SmithNetwork Troubleshooter\[The following discussion is in response to Michael Dragone's "Colasoft Capsa 7.1" review (InstantDoc ID 125186)\]\[Colasoft Capsa 7.1\] sounds like a great network sniffer. I'm always using Wireshark as my troubleshooting tool, but now you make me \[want to\] try this one, too.—Hu