The following is a collection of expert responses to reader questions by Jeremy Moskowitz.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
How can I prevent users from installing software on PCs within the domain?
Jeremy Moskowitz:The best, but hardest, way is via Software Restriction Policies. The goal of Software Restriction Policies is to have you specifically dictate what can and cannot run. In other words, you can specify that users can't even run the installation utility to software applications unless you've approved it. Be sure to check out Software Restriction Policies. They're great!
For some reason, the network firewall profile in our AD Domain environment that is effective for our workstations is the "Standard" profile. I tried disabling the standard profile with the netsh command unsuccessfully. The standard setting works, but, as I understand, the "Domain" profile settings should be used. The standard should only be effective if the workstation is removed from the Domain.
JM: The Standard profile and Domain profile firewall settings serve two different purposes. The Standard profile is meant to be used when users aren't authenticating to a Domain Controller. The Domain profile is meant for when they are authenticating to a Domain Controller. Therefore, you can have, say, a stronger set of restrictions while out of the office as opposed to when they're in the office.
Our shop runs Windows 2000 AD on Windows 2000 Professional Workstations. Both the user accounts and workstations can be moved to a new OU/s if required. I could possibly do this via a KIXTART script or some other means but I would prefer to keep this control within my Directory. I want to designate specific administrators to specific PCs. How do I do this?
JM:Group Policy to the rescue! You can easily do this using the Restricted Groups functionality. First, create a new GPO and link it to an OU containing these particular computers. Then, using Restricted Groups, enter the name of the local group you want -- for example, Administrators. Then, add the generic users you want to be administrators. However, a quick warning: This is a "rip and replace" function. That is, if anyone is currently an administrator on the machine (for instance, the Domain Administrator), they'll be "ripped" out and "replaced" with the users you specify. So -- be careful!
When creating the System Update policy for enabling SUS, how do you set the ability to use the Microsoft Windows Update server in the event that new updates become available and the workstation in question is not attached to the domain (i.e. traveling laptop)?
JM:Traveling laptops must connect sometime. And, when they do, they'll get updates. There is no easy "magical way" for them to get SUS updates. So, my philosophy is to use SUS for when you've got desktops, but let your laptop users use the standard automatic Microsoft update service. That way, they'll get a constant stream of updates -- even if they're not connected to your network. My view might be unpopular, though, because in theory, all patches you roll out should be tested. However, when you cut laptop users free, you're essentially saying, "Well, I hope that new patch they download doesn't crash Windows." To that end, you might be better served with a third-party patch management system that accounts for laptops.
I recently set up a new Windows server 2003. I created a couple test users and put them in groups. I also created some GPOs and linked them. As far as I can tell everything is configured properly on the server side. My question is, when I log onto the domain from my test client computer, it does not pull down the GPO for the group they are in. I feel there is something I need to do on the client side, but I am not sure. How can I pull the GPO to the W2K client computer from AD?
JM:You said you linked the GPO to the correct location. But you didn't say to where. I'm guessing you linked the GPOs to a place that has no user or computer accounts; hence, you won't see much action. Or, maybe you created the GPO, but didn't actually link it anywhere. Don't feel bad though -- I make mistakes like this all the time. Be sure to click on the Scope tab using GPMC and look at the "Links" field to see, specifically, where the GPO is linked to. That should help you determine if you're really linked or not.
Jeremy Moskowitz, a Microsoft Most Valuable Professional (MVP) and Microsoft Certified Systems Engineer (MCSE), is an independent consultant and trainer for Microsoft Windows technologies. He runs two community forums, www.GPanswers.com and www.WinLinAnswers.com, that answer tough questions about Group Policy and Windows/Linux integration. Jeremy's latest book, Windows and Linux Integration: Hands-on Solutions for a Mixed Environment (Sybex, 2005), is available at WinLinAnswers.com. His popular book, Group Policy, Profiles, and IntelliMirror (Sybex, 2005) is available at www.GPanswers.com.