Posted by jayb | Posted on 31-10-2009
Category : microsoft, technology
Tags: active directory, GPO, windows7
At work we will start testing Windows 7 within the IS department Q2 next year. Our current AD forest is still in mixed mode 2000!!! So I have some cleanup and upgrades todo on that before I start working about windows 7 GPO’s. I just need to retire and move the roles of the old 2000 DC’s. We are also retiring a few domains and merging into the forest root and utilize OU’s better. Below is good information about windows 7 GPO’s once I get there next year.
Now that you’ve obviously purchased, installed, and started playing with your Windows 7 client, you’re probably fantasizing about all the great things that will happen to your environment when you upgrade all of the machines in your site / OU / domain / basement to Windows 7 as well. Let me tell you, it’s going to be great. Why? Because you’ll have GP Preferences client side extensions installed already in all of those Windows 7 clients! That means that you can map drives and push out shortcuts and add printers and configure power plans for all these Windows 7 machines from your own Windows 7 client (with RSAT) or with Windows Server 2008 R2.
To answer the question in the title, NO, you do not need to change your update your Active Directoy (if it’s at least 2003) to take advantage of sweet new Group Policy features and settings. The exception is if the application that the setting is relevant to requires an AD upgrade, like BitLocker. This is a good article on configuring BitLocker in your AD, written by the guys on the Directory Services team: http://blogs.technet.com/askds/archive/2009/08/18/bitlocker-and-active-directory.aspx
Also – check out an overview plus good getting started tips on this website: Group Policy Management for IT Pros. If there was anything in the above paragraphs that you have questions on, read this article first. Seriously.
http://windows.microsoft.com/et-EE/windows7/Group-Policy-management-for-IT-pros
Have fun! Go Preferences!
LiliaG (@superlilia)
Windows 7 – Do I need to change my Active Directory for new Group Policy features?
GPTeam
Tue, 27 Oct 2009 08:31:00 GMT
Posted by jayb | Posted on 25-09-2009
Category : microsoft, technology
Tags: active directory, GPO
The Directory Services Team at MS has wrong two very good blog post about troubleshooting slow logons for workstations.
Here’s a clip from So you have a slow logon…? (Part 1)
- Outdated drivers: Your network interface card (NIC) should use the latest drivers installed.
- Outdated operating system (OS) patch level: Your operating system should have the latest service pack installed from windows update
- Roaming user profiles: Roaming profiles change the way group policy processing is performed. When roaming profiles are configured the processing is changed from “asynchronous” (background processing or multiple at a time) to “synchronous” (foreground processing or one at a time). This disables “Fast logon Optimization” which will delay the user getting the desktop by waiting for the network to initialize first.
Note: This is really important to understand that when roaming profiles are implemented, group policy software installations and folder redirection requires that the user is NOT logged on before the network is initialized and processes policy synchronously- ONE AT A TIME. This is the default behavior and changing it could cause inconsistencies with your logon.
- Home folders: This could impact your logon times because instead of looking at a local location for system DLL’s, the client machine will look for them in the home folder instead. If that mapped network share is across a wide area network (WAN) link that is slow you can bet that your logon time is going to suffer even more.
Note: If home folders are needed with roaming profiles there is a registry key tweak (SafeDllSearchMode) that can be added that will change the behavior. If you’re not sure that this is an issue in your environment, take a network trace at logon and see if DLL’s are being queried across the network to the home folder. There is also another tweak on the same page (StartRunNoHOMEPATH) that will assist with applications doing this behavior.
- Start up applications: Applications that are configured to automatically run during startup will slow the logon down.
- Profile scanning: There are many antivirus software applications that will scan profiles at login and at their home location if they are roaming. This is not limited to just antivirus software but other applications will as well. (In the troubleshooting section we will review how to discover if this is happening)
- Excessive group policies: Having a ton of group policies that perform extensive tasks or configurations (like software restrictions) will increase your logon time. A few policies that accomplish everything are better than many policies that do a handful of things each. If possible consolidate your group policies.
- Excessive startup/logon scripts: Scripts that run at logon or start up can delay the process significantly if they perform a lot of tasks or use inefficient code
- Excessive WMI filters: Having excessive WMI filters can slow group policy processing
- No local domain controllers: Not having local domain controllers (users authenticating across a wide area network-WAN) will cause a logon delay
Continue Reading
Posted by jayb | Posted on 09-07-2008
Category : Post from around the Net, microsoft, technology
Tags: activedirectory, admin, GPO, microsoft, nac, scripts, security, servers, windows, WP, XP
Thank you so much Jorge and the activedir.org mailing list. I’ve been trying to figure out how to get a junior admin access to restart the print spooler on a windows 2003 SP1 box for over a month.
Delegating permissions to manage services on servers is not the easiest thing to do. You can do it from the command line or through a GPO in the “System Services” node. Either way you MUST take the current configured permissions into account, otherwise you might/will experience issues!
I do not like to use a GPO to do this and prefer to use command line tools in scripts. I’m not going to post a script, but I’m going to provide the information for the delegation of the permissions required and how to achieve that. For the scripting part, what you need to do is retrieve the current SDDL, add what you want to add and write the complete new SDDL back.
Jorge ‘s Quest For Knowledge! : Delegating Monitoring/Stopping/Starting services on Servers
Continue Reading
Most of these tips are very basic. But we all need to start somewhere.
The initial settings that you should make to get Active Directory secure for your network before you dive into setting up the entire structure.
1.Create an Administrative Account for Yourself
2.Set a Complex and Long Password for the Administrator Account
Top 10 Security Settings to make directly after Installing Active Directory
Here’s a great article about group policy. I didn’t realize that you could set ACL’s on files using GPO’s that’s sweet. To bad the Event Viewer for Operational Logs isn’t available for XP or 2003. 
If you haven’t already seen it, check out my article in this month’s TechNet Magazine on "Optimizing Group Policy Performance". The article goes into fair bit of detail about things you can do (or not do) to ensure that GP performance is good on your Windows systems. But one thing I didn’t get into is how some specific Client Side Extension (CSE) behaviors can cause performance slowdowns. I received an email from someone at Microsoft asking about this yesterday. His specific question was around the performance impact of using GP to set file system or registry security. GP today has that capability under Computer Configuration/Windows Settings/Security Settings/File System (or Registry). But of course, if you use this feature against large numbers of files or folders (or reg keys), its going to take a while to modify ACLs on those objects, just as it would if you are doing it through Explorer. But his question had to do with the impact of this on system performance, if GP processed these ACL changes every time processing ran. The answer, of course, is that GP processing settings only if one of several situations occur. First, if *something* changes in the GP environment, a client will process those changes during the next processing cycle (I talk about what those changes could be in the article).
The other scenario where security policy would process every time GP processes is if an administrator explicitly told it to do so by setting the per-computer policy at Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing\Process even if the Group Policy Objects have not changed. Now of course, enabling this setting can have a very obvious impact on system performance if what you’re doing in security policy are expensive operations like file system re-ACLing. But if not, the advantage of using this setting is that you ensure that, every 90 minutes or so, any security policy you have defined will be re-applied, just in case a pesky user figured out a way to undo them (which they should not if they are not administator on their systems, right????). But in general, I would leave this setting alone.
The 3rd scenario where security policy would process is by virtue of its own built-in behavior. That is, the Security CSE will process security policy every 16 hours by default, regardless of what else is happening. This is a failsafe that MS decided to put into security policy so that security policy will get re-applied if the environment is reasonably static. You can actually modify this interval to be something other than 16 hours via a registry tweak (I actually created a custom ADMX file for this that will be on the CD in the upcoming Windows Server 2008 Resource Kit book, which I wrote the GP chapter for). The registry tweak info can be found at http://support.microsoft.com/kb/277543/en-us.
Tags:
Group Policy, Security Policy, TechNet Magazine
Group Policy Performance and Security Policy
gpoguy
Thu, 17 Jan 2008 22:15:57 GMT
Posted by jayb | Posted on 07-12-2007
Category : microsoft, technology
Tags: GPO, RDP, remote desktop, windows, XP
To take over the control the remote XP computer, click the Take Control on the top right. If you can’t take the control, make sure Allow helpers to remotely control the computer under Offer Remote Assistance Setting is enabled. By default, Offer Remote Assistance Settings is disabled. To do enable it, open Group Policy by running gpedit.msc. go to Local Computer Policy\Computer Configuration\Administrative Templates\System\Remote Assistance. The user who will be giving assistance must be a member of the Local Administrators Group on the receiving machine or you need to added as a Helper in the Offer Remote Assistance Group Policy Setting. To add User and Groups to Group Policy: Go to Offer Remote Assistance Group Policy, and in the Helpers area, click Show. Click Add and then enter the Domain\user account
In a case you want to remote access a Windows XP professional workstation and the computer Remote Desktop is not enabled, or no one over there to help you to enable it, you may have an option to enable Remote Desktop remotely by using regedit.
To enabling Remote Desktop using regedit, follow these steps:
- Run REGEDIT from Start>Run
- Click on File, then select Connect Network Registry
- Type the remote computer IP or host name in the Enter the object name to select and the click OK.
4. If you don’t have permission to access the remote computer, the logon screen will show up. Type the username and password for the remote computer. Then click OK.
5. Now, the remote computer is listed in the Registry Editor.
6. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server, in the right panel, select fDenyTSConnection (REG_DWORD). Change the value data from 1 (Remote Desktop disabled) to 0 (Remote Desktop enabled).
7. Close the regedit.
Now you can use remote support
