10.29.07
Posted in PowerShell at 4:12 pm by Administrator
Jeff Hicks, scripting-guy extraordinaire at scripting solutions vendor Sapien, wrote a nice article on the Redmond Magazine website about scripting Group Policy with PowerShell. He specifically talks about our free GPOGUY PowerShell cmdlets and how you can use them to perform basic GP administratiion tasks, and then goes on to mention the GPExpert Scripting Toolkit for using PowerShell to make actual changes to Group Policy settings. Cool article! Thanks Jeff.
Tags:
Group Policy, PowerShell, Sapien, GPExpert Scripting Toolkit, GPOGUY
Permalink
10.15.07
Posted in Office at 6:29 am by Administrator
Microsoft has finally shipped some ADMX template files for configuring Office 2007! They are available here. That’s good news–now you can use the new template format to customize Office 2007 deployments in your Vista environments without dragging around ADM files in every GPO.
As you may know, one of the downsides of the old ADM files is that they were copied into the SYSVOL portion of each GPO that used them. This meant a lot of duplicate ADM files in your GPOs, replicating 2-3MB of stuff to every DC. ADMX files do away with that in Vista and Windows Server 2008. When you’re editing GPOs in those environments, the ADMX files are referenced from either the c:\windows\policydefinitions location or from something called the Central Store. The "Central Store" is a folder you create manually in SYSVOL (or you can use my free Central Store Creator Utility) and can be referenced by any administrator editing policy from Vista or Server 2008. Now that Microsoft has shipped Office ADMX files, you don’t have to have Office ADMs running around every GPO in SYSVOL–you can put them in your Central Store and away you go!
Tags
Group Policy, Microsoft Office 2007, ADMX, GPOGUY
Permalink
10.08.07
Posted in registry policy at 1:18 pm by Administrator
In my previous post I talked about security policy and its tattooing ways. But how about a scenario where a policy should not have tattooed, and did? That was the situation when I got an email from someone about a policy that was tattooing their systems. The situation was, they had created a custom ADM file that set a registry value under the policy keys, which should get removed when the policy is removed. Let’s say it was set under HKLM\Software\Policies\Myapp1. They then needed to update the app and also the ADM file to make changes to HKLM\Software\Policies\Myapp2. So they removed the original ADM from the GPO that had delivered this setting and added the new one. And low and behold, after applying the new policy to the GPO their target systems had both settings! Why?
Well, let’s think about the way that this works. The ADM file basically lets you set a registry policy for a particular registry key and value. Its your window into the underlying registry.pol file, which stores the actual registry settings in the GPO. When that user removed the first ADM, they were only removing that window into the setting–the setting itself was not removed from the GPO and so as long as the GPO was applying to that system, so was the old setting. They added the new ADM file, enabled the new registry location and Voila!–registry settings in both the old and new locations.
The moral of that story is, when you need to retire a policy setting, you have two choices. Either set the policy setting to not configured and then remove the ADM. Or, remove the GPO altogether so that the policy no longer applies to the target.
In the next blog on this topic, I’ll talk about how a similiar thing can affect machines that you remove from the domain, that end up having policy settings tattooed all over them…
Tag:
Group Policy, registry tattooing, Administrative Templates
Permalink
10.05.07
Posted in General Stuff at 2:13 pm by Administrator
Many of you probably know who Mark Minasi is. Mark’s been writing and speaking on Windows for a very long time. Mark is a good friend as well and a really good guy. He maintains a very active Forum, on which I moderate the Group Policy section. If you haven’t checked out his forum, I highly suggest it. There are a ton of smart people who lurk there and you’ll find sections for just about any technology you can imagine.
For the past two years, Mark has hosted the Minasi Forum Meeting on the East coast of the US. Think of it as a micro-TechEd. Its an opportunity for forum members to meet each other face-to-face and for some of the experts on the forum to teach classes to other members. Its a great opportunity for some serious technical training in an atmosphere that much more personal than what you find at conferences with thousands of people. I went this year and really enjoyed myself. Well, they’re doing it again next year and if you’re interested, I highly recommend you visit the forum meeting site and check it out. There is a registration fee but I think its some of the best conference money you will spend. The site is at : http://www.minasi.com/forummeet2008
Permalink
Posted in Security Policy at 9:46 am by Administrator
Under the category of "you learn something new every day" I was playing around with some stuff yesterday and finally got a chance to confirm something that someone had posted on the ActiveDir mailing list. We all know about how some policies tattoo the registry. Security policies are typically one of those areas where, if you remove a setting, the systems applying that policy are not necessarily reverted back to the prior setting because, well, the system doesn’t necessarily know what the prior setting is. You can imagine that this may be a good idea if by accident you remove a policy that hardens your servers and suddenly the servers decide to revert back to a less restrictive setting.
However, one area that does not follow this model is Restricted Group policy, as I came to discover yesterday. Namely, if I use the part of Restricted Groups called "Members of this Group" to exclusively control the membershp of a particular group, and then remove that policy, the next time that policy is refreshed on the target computer that holds the group, that group’s membership is reverted to the list of members that were there before the policy applies. This is probably documented somewhere but its one of those myriad of things that I hadn’t looked at specifically before and so I thought it was interesting.
Not content with stopping there, I tried one more test. I tried applying the restricted groups policy to an AD group and then removed it to see what the effect would be. Now, I’ve blogged in the past about why using Restricted Groups polciy against AD groups was a bad idea, but this experiment was all about knowledge, so I figured I could break my rules a bit. And what was the result? Well if you guessed that after removing the Restricted Groups policy on an AD group, that the membership would be reverted back to the old one as well, you’d be wrong! Its not too surprising really. First off, I imagine that on computer-based groups, that the membership is probably stored in the local SAM and remains there even when Restricted Groups policy is in place. Its cached, if you will. There is no place for AD to cache group memberships and I’m sure doing so would cause all kinds of issues.
Tag:
Group Policy, Restricted Groups, Security Policy
Permalink
10.03.07
Posted in PowerShell at 4:04 pm by Administrator
Just a quick note to let folks know that I’m going to be giving a webinar on our GPExpert™ Scripting Toolkit for PowerShell product next Wednesday, October 10th, at 8:30am Pacific Time. In this webinar, I’ll go over how you can use the Scripting Toolkit and Microsoft’s PowerShell scripting environment to manage the settings within a Group Policy object, such as Administrative Templates, Software Installation, Security policy, etc. I hope you can join me for this. To attend just register at: https://sdmsoftware.webex.com/sdmsoftware/j.php?ED=100098272&RG=1
Tags:
Group Policy, Powershell, GPExpert Scripting Toolkit, SDM Software
Permalink
