Blog - Title

June, 2011

  • What is the Impact of Upgrading the Domain or Forest Functional Level?

    Hello all, Jonathan here again. Today, I want to address a question that we see regularly. As customers upgrade Active Directory, and they inevitably reach the point where they are ready to change the Domain or Forest Functional Level, they sometimes become fraught. Why is this necessary? What does this mean? What’s going to happen? How can this change be undone?

    What Does That Button Do?

    Before these question can be properly addressed, if must first be understood exactly what purposes the Domain and Forest Functional Levels serve. Each new version of Active Directory on Windows Server incorporates new features that can only be taken advantage of when all domain controllers (DC) in either the domain or forest have been upgraded to the same version. For example, Windows Server 2008 R2 introduces the AD Recycle Bin, a feature that allows the Administrator to restore deleted objects from Active Directory. In order to support this new feature, changes were made in the way that delete operations are performed in Active Directory, changes that are only understood and adhered to by DCs running on Windows Server 2008 R2. In mixed domains, containing both Windows Server 2008 R2 DCs as well as DCs on earlier versions of Windows, the AD Recycle Bin experience would be inconsistent as deleted objects may or may not be recoverable depending on the DC on which the delete operation occurred. To prevent this, a mechanism is needed by which certain new features remain disabled until all DCs in the domain, or forest, have been upgraded to the minimum OS level needed to support them.

    After upgrading all DCs in the domain, or forest, the Administrator is able to raise the Functional Level, and this Level acts as a flag informing the DCs, and other components as well, that certain features can now be enabled. You'll find a complete list of Active Directory features that have a dependency on the Domain or Forest Functional Level here:

    Appendix of Functional Level Features
    http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(WS.10).aspx

    There are two important restrictions of the Domain or Forest Functional Level to understand, and once they are, these restrictions are obvious. Once the Functional Level has been upgraded, new DCs on running on downlevel versions of Windows Server cannot be added to the domain or forest. The problems that might arise when installing downlevel DCs become pronounced with new features that change the way objects are replicated (i.e. Linked Value Replication). To prevent these issues from arising, a new DC must be at the same level, or greater, than the functional level of the domain or forest.

    The second restriction, for which there is a limited exception on Windows Server 2008 R2, is that once upgraded, the Domain or Forest Functional Level cannot later be downgraded. The only purpose that having such ability would serve would be so that downlevel DCs could be added to the domain. As has already been shown, this is generally a bad idea.

    Starting in Windows Server 2008 R2, however, you do have a limited ability to lower the Domain or Forest Functional Levels. The Windows Server 2008 R2 Domain or Forest Functional level can be lowered to Windows Server 2008, and no lower, if and only if none of the Active Directory features that require a Windows Server 2008 R2 Functional Level has been activated. You can find details on this behavior - and how to revert the Domain or Forest Functional Level - here.

    What Happens Next?

    Another common question: what impact does changing the Domain or Forest Functional Level have on enterprise applications like Exchange or Lync, or on third party applications? First, new features that rely on the Functional Level are generally limited to Active Directory itself. For example, objects may replicate in a new and different way, aiding in the efficiency of replication or increasing the capabilities of the DCs. There are exceptions that have nothing to do with Active Directory, such as allowing NTFRS replacement by DFSR to replicate SYSVOL, but there is a dependency on the version of the operating system. Regardless, changing the Domain or Forest Functional Level should have no impact on an application that depends on Active Directory.

    Let's fall back on a metaphor. Imagine that Active Directory is just a big room. You don't actually know what is in the room, but you do know that if you pass something into the room through a slot in the locked door you will get something returned to you that you could use. When you change the Domain or Forest Functional Level, what you can pass in through that slot does not change, and what is returned to you will continue to be what you expect to see. Perhaps some new slots added to the door through which you pass in different things, and get back different things, but that is the extent of any change. How Active Directory actually processes the stuff you pass in to produce the stuff you get back, what happens behind that locked door, really isn't relevant to you.

    If you carry this metaphor forward into the real world, if an application like Exchange uses Active Directory to store its objects, or to perform various operations, none of that functionality should be affected if the Domain or Forest Functional Mode changes. In fact, if your applications are also written to take advantage of new features introduced in Active Directory, you may find that the capabilities of your applications increase when the Level changes.

    The answer to the question about the impact of changing the Domain or Forest Functional Level is there should be no impact. If you still have concerns about any third party applications, then you should contact the vendor to find out if they tested the product at the proposed Level, and if so, with what result. The general expectation, however, should be that nothing will change. Besides, you do test your applications against proposed changes to your production AD, do you not? Discuss any issues with the vendor before engaging Microsoft Support.

    Where’s the Undo Button?

    Even after all this, however, there is a great concern about the change being irreversible, so that you must have a rollback plan just in case something unforeseen and catastrophic occurs to Active Directory. This is another common question, and there is a supported mechanism to restore the Domain or Forest Functional Level. You take a System State back up of one DC in each domain in the forest. To recover, flatten all the DCs in the forest, restore one for each domain from the backup, and then DCPROMO the rest back into their respective domains. This is a Forest Restore, and the steps are outlined in detail in the following guide:

    Planning for Active Directory Forest Recovery
    http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery(WS.10).aspx

    By the way, do you know how often we’ve had to help a customer perform a complete forest restore because something catastrophic happened when they raised the Domain or Forest Functional Level? Never.

    Best Practices

    What can be done prior to making this change to ensure that you have as few issues as possible? Actually, there are some best practices here that you can follow:

    1. Verify that all DCs in the domain are, at a minimum, at the OS version to which you will raise the functional level. Yes… I know this sounds obvious, but you’d be surprised. What about that DC that you decommissioned but for which you failed to perform metadata cleanup? Yes, this does happen.
    Another good one that is not so obvious is the Lost and Found container in the Configuration container. Is there an NTDS Settings object in there for some downlevel DC? If so, that will block raising the Domain Functional Level, so you’d better clean that up.

    2. Verify that Active Directory is replicating properly to all DCs. The Domain and Forest Functional Levels are essentially just attributes in Active Directory. The Domain Functional Level for all domains must be properly replicated before you’ll be able to raise the Forest Functional level. This practice also addresses the question of how long one should wait to raise the Forest Functional Level after you’ve raised the Domain Functional Level for all the domains in the forest. Well…what is your end-to-end replication latency? How long does it take a change to replicate to all the DCs in the forest? Well, there’s your answer.

    Best practices are covered in the following article:

    322692 How to raise Active Directory domain and forest functional levels
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;322692

    There, you’ll find some tools you can use to properly inventory your DCs, and validate your end-to-end replication.

    Update: Woo, we found an app that breaks! It has a hotfix though (thanks Paolo!). Mkae sure you install this everywhere if you are using .Net 3.5 applications that implement the DomainMode enumeration function.

    FIX: "The requested mode is invalid" error message when you run a managed application that uses the .NET Framework 3.5 SP1 or an earlier version to access a Windows Server 2008 R2 domain or forest  
    http://support.microsoft.com/kb/2260240

    Conclusion

    To summarize, the Domain or Forest Functional Levels are flags that tell Active Directory and other Windows components that all DCs in the domain or forest are at a certain minimal level. When that occurs, new features that require a minimum OS on all DCs are enabled and can be leveraged by the Administrator. Older functionality is still supported so any applications or services that used those functions will continue to work as before -- queries will be answered, domain or forest trusts will still be valid, and all should remain right with the world. This projection is supported by over eleven years of customer issues, not one of which involves a case where changing the Domain or Forest Functional Level was directly responsible as the root cause of any issue. In fact, there are only cases of a Domain or Forest Functional Level increase failing because the prerequisites had not been met; overwhelmingly, these cases end with the customer's Active Directory being successfully upgraded.

    If you want to read more about Domain or Forest Functional Levels, review the following documentation:

    What Are Active Directory Functional Levels?
    http://technet.microsoft.com/en-us/library/cc787290(WS.10).aspx

    Functional Levels Background Information
    http://technet.microsoft.com/en-us/library/cc738038(WS.10).aspx

    Jonathan “Con-Function Junction” Stephens

  • Fun with the AD Administrative Center

    Hi folks, Ned here again. We introduced the AD Administrative Center in Windows Server 2008 R2 to much fanfare. Wait, I mean we told no one and for good measure, we left the old AD Users and Computers tool in-place. Then we continued referencing it in all our documentation.

    And people say we're a marketing company.

    I've talked previously about using ADAC as a replacement for acctinfo.dll. Today I run through some of the hidden coolness that ADAC brings to the table as well as techniques that make using it easier. If you're never used this utility, make sure you review the requirements and if you don't have any Windows Server 2008 R2 DCs, install the AD Management Gateway and its updates on at least one of your older DCs in each domain. ADAC is included in RSAT.

    I am going to demo as much as possible, so I hope you have some bandwidth this month, oppressed serfs Canucks and Aussies. Since this is me, I'll also show you how to work around some ADAC limitations - this isn’t a sales pitch. To make things interesting, I am using one of my more complex forests where I test the ADRAP tools.

    image

    Fire up DSAC.EXE and follow along.

    ADAC isn't ADUC

    The first lesson is "do not fight the interface". Don’t try to make ADAC into AD Users and Computers simply because that's what you’re used to. ADUC wants to click everywhere, expanding trees of data. It's also has short-term memory loss - every time you restart it you have to set it up all over again.

    ADAC realizes that you probably stick to a few areas most of the time. So rather than heading to the Tree View tab right away to start drilling down, like this:

    image

    … instead, consider using navigation nodes to add areas you are frequently accessing. In my case here, the Users container is an obvious choice:

    image

    image

    This pins that container in the navigation pane so that I don’t have to click around next time.

    image

    It's even more useful if I use many deeply nested OU structures in the domain. For example, rather than clicking all the way into this hierarchy each time:

    image

    I can instead pin the areas I plan to visit that week for a project:

    image

    Nice! It even preserves the visual hierarchy for me. Notice another thing here - ADAC keeps the last three areas I visited in the recent view list under that domain. Even if I had not pinned that OU, I'd still get it free if I kept returning to it:

    image

    Once you open one of those users, you don't have to dig through a dozen tabs for commonly used attributes. The important stuff is right up front.

    image

    For a real-world example of how this does not suck, see this article. The old tabs are down there in the extensions section still, if you need them:

    image

    A lot of people have a lot of domains

    One thing AD Users and Computers isn’t very good at is scale: it can only show you one domain at a time, requiring you to open multiple dialogs or create your own custom MMC console.

    image

    In ADAC, it’s no sweat - just insert any domains you want using Add Navigation Nodes again:

    image

    I can add other navigation nodes for those domains without adding the domains themselves too. Each domain gets that three-entry "recently used" list too. I'm also free to move the pinned nodes up and down the list with the right-click menu, if I have OCD. For instance, if I want the Users and Computers container from three domains, it's nothing to have them readily available, in the order I want:

    image

    image

    Come on now, you have to admit that is slick, right?

    Always look for the nubbin arrow

    Scattered around the UI are little arrows that allow you to hide and expose various data views. For instance, you can give yourself more real estate by hiding the navigation pane:

    image

    Or see a user's logon information:

    image

    Or hide a bunch of sections in groups that you don't usually care about, leaving the one you constantly examine:

    image

    Note: It's not really called the nubbin arrow except by Mike Stephens and me. Join our cool gang!

    Views and Search are better than Find

    AD Users and Computers is an MMC snap-in: this means a UI designed for NT 4.0. When it lets you search, you are limited to the Find menu, which lets you return data, but not preserve it. After closing each search, ADUC's moron brain forgets what you just asked, like a binary pothead.

    ADAC came after the birth of search and in a time where AD is now ubiquitous and huge. That means everywhere you go, it wants to help you search rather than browse. Moreover, it wants to remember things you found useful. If I am looking at my Users container, the Filter menu is right there beckoning:

    image

    It lets me do quick and reasonable searches without a complicated menu system:

    image

    As well as create complex queries for common attributes:

    image

    Then save those queries for later, for use within any spot in the forest:

    image

    I can also use global search. And I do mean global - for example, I can search all my domains at once and not be limited to Global Catalog lookups that are often missing less-travelled attributes:

    image

    For example here, I use ambiguous name resolution to find all objects called Administrator - note how this automatically wildcards.

    image

    Not bad, but I want only users that are going to have their passwords expire in the next month. Moreover, I've been trying to improve my LDAP query skills when scripting. No sweat, I can do it the easy way then convert it to LDAP:

    image

    image

    Or maybe I let ADAC do the hard work of things like date range calculation:

    image

    Then I take that query:

    image

    And modify it to do what I want. Like only show me groups modified in the past three days:

    image

    Neato - on demand quasi-auditing.

    A few tricks of the trade

    Return to defaults

    If you want to zero out the ADAC console and get an out of box experience, there's no menu or button. However, if you delete this folder, you delete the whole cache of settings:

    %appdata%\IsolatedStorage\StrongName.um0icba0dwq40nfvuftw3i5jvholhn3k

    ADAC will be slow to start the next time you run it (just as it was the first time you ever ran it) but it will be quick again after that.

    The Management List

    Have some really ginormous containers? If you navigate into one using ADAC, you will see an error like this:

    image
    "The number of items in this container exceeds the maximum number blah blah blah…"

    The error tells you what to do - just change the "Management List" options. Right! So… ehhh… where is the management list? You have to hit the ALT key to expose that menu. Argh…

    image

    Then you can set the turned object count as low as 2000 or as high as 100000. If you have to do this though, you need to work on organizing your objects better.

    Just think "Explorer"

    In many ways, we designed ADAC like 7's Windows Explorer. It has a breadcrumb bar, a refresh button, and forward/back buttons.

    image

    It lets you use the address bar to quickly navigate and browse, with minimal real estate usage.

    image

    The buttons offer a history:

    image

    It has an obvious and "international" refresh button - very handy. ADUC made you learn weird habits like F5, which may seem natural to you now, but isn't not very friendly for new admins.

    image

    That new Explorer probably took some getting used to but once you had them, returning to XP seems like visiting the dusty hometown you left years ago: Quaint. Inefficient. Boring. Having used the new one for a few years now, ADAC should be more intuitive.

    Sum Up

    I'm not here to argue against AD Users and Computers; it has its advantages (I miss the Copy… menu). And it's certainly familiar after 11 years of use. However, the AD Administrative Center deserves a place at any domain admins' table and can make your life easier once you know where to look. Try it for a week and see for yourself. If you come back to ADUC, it's ok - we already cashed your check.

    Until next time.

    - Ned "Ok, maybe 'fun' was a stretch" Pyle

  • Target Group Policy Preferences by Container, not by Group

    Hello again AskDS readers, Mike here again. This post reflects on Group Policy Preference targeting items, specifically targeting by security groups. Targeting preference items by security groups is a bad idea. There is a better way that most environments can accomplish the same result, at a fraction of the cost.

    Group Membership dependent

    The world of Windows has been dependent on group membership for a long time. This dependency is driven by the way Windows authorizes access to resources. The computer or user must be a member of the group in order to access the printer or file server. Groups are and have been the bane of our existence. Nevertheless, we should not let group membership dominate all aspects of our design. One example where we can move away from using security groups is with Group Policy Preference (GPP) targeting.

    Targeting by Security Group

    GPP Targeting items control the scope of application for GPP items. Think of targeting items as Group Policy filtering on steroids, but they only apply to GPP items included in a Group Policy object. They introduce an additional layer of administration that provides more control over "how" GPP items apply to a specific user or computer.

    image
    Figure 1 - List of Group Policy Preference Targeting items

    The most common scenario we see using the Security Group targeting item is with the Drive Map preference item. IT Professionals have been creating network drive mappings based on security groups since Moby Dick was a sardine-- it's what we do. The act is intuitive because we typically apply permissions to the group and add users to the group.

    The problem with this is that not all applications determine group membership the same way. Also, the addition of Universal Groups and the numerous permutations of group nesting make this a complicated task. And let's not forget that some groups are implicitly added when you log on, like Domain Users, because it’s the designated primary group. Programmatically determining group membership is simple -- until it's implemented, and its implementation's performance is typically indirectly proportional to its accuracy. It either takes a long time to get an accurate list, or a short time to get a somewhat accurate list.

    Security Group Computer Targeting

    Using GPP Security Group targeting for computers is a really bad idea. Here's why: in most circumstances, the application retrieves group memberships from a domain controller. This means network traffic from the client to the domain controller and back again. Using the network introduces latency. Latency introduces slow process, and slow processing is the last thing you want when the computer is processing Group Policy. Also, Preference Targeting allows you to create complex targeting scenarios using Boolean operators such as AND, OR, and NOT. This is powerful stuff and lets you combine one or more logon scripts into a single GP item. However, the power comes at a cost. Remember that network traffic we created by make queries to the domain controller for group memberships? Well, that information is not cached; each Security Group targeting item in the GPO must perform that query again- yes, the same one it just did. Don't hate, that's just the way it works. This behavior does not take into account nest groups. You need to increase the number of round trips to the domain controller if you want to include groups of groups of groups etcetera ad nauseam (trying to make my Latin word quota).

    Security Group User Targeting

    User Security Group targeting is not as bad as computer Security Group targeting. During user Security Group targeting, the Group Policy Preferences extension determines group membership from the user's authentication token. This process if more efficient and does not require round trips to the domain controller. One caveat with depending on group membership is the risk of the computer or user's group membership containing too many groups. Huh- too many Groups? Yes, this happens more often than many realize. Windows creates an authentication token from information in the Kerberos TGT. The Kerberos TGT has a finite amount of storage for this information. User and computers with large group memberships (groups nested with groups…) can maximize the finite storage available in the TGT. When this happens, the remaining groups memberships are truncated, which creates the effect that the user is not a member of that group. Groups truncated from the authentication token results in the computer or user not receiving a particular Group Policy preference item.

    You got any better ideas?

    A better choice of targeting Group Policy Preference items is to use Organization Unit targeting items. It's da bomb!!! Let's look at how Organizational Unit targeting items work.

    image
    Figure 2 Organizational Unit Targeting item

    The benefits Organizational Unit Targeting Items

    Organization Unit targeting items determines OU container membership by parsing the distinguished name of the computer or user. So, it simply uses string manipulation to determine what OUs are in scope with the user or computer. Furthermore, it can determine if the computer or user has direct container membership of an OU by simply looking for the first occurrence of OU immediately following the principal name in the distinguished name.

    Computer Targeting using OUs

    Computer Preference targeting with OUs still has to contact a domain controller. However, it’s an LDAP call and because we are not chasing nested groups, it's quick and efficient. First, the preference client-side extension gets the name of the computer. The CSE gets name from the local computer, either from the environment variable or from the registry, in that order. The CSE then uses the name to look up the security identifier (SID) for the computer. Windows performs an LDAP bind to the computer object in Active Directory using the SID. The bind completes and retrieves the computer object's distinguished name. The CSE then parses the distinguished name as needed to satisfy the Organizational Unit targeting item.

    User Targeting using OUs

    User Preference targeting requires fewer steps because the client-side extension already knows the user's SID. The remaining work performed by the CSE is to LDAP bind to the user object using the user's SID and retrieve the distinguished name from the user object. Then, business as usual, the CSE parses the distinguished name to satisfy the Organizational Unit targeting item.

    Wrap Up

    So there you have it. The solution is clean and it takes full advantage of your existing Active Directory hierarchy. Alternatively, it could be the catalyst needed to start a redesign project. Understandably, this only works for Group Policy Preferences items; however-- every little bit helps when consolidating the number of groups to which computer and users belong-- and it makes us a little less dependent on groups. Also, it's a better, faster, and more efficient alternative over Security Group targeting. So try it.

    Update

    We recently published a new article around behavior changes with Group Policy Preferences Computer Security Group Targeting.  Read more here.

    - Mike "This is U.S. History; I see the globe right there" Stephens

     

     

  • Forcing Domain Admins to use AGPM (but not really)

    Hi folks, Sean Wright here for my final post. So, you have AGPM installed, but your Domain Admins continue using GPMC to create, delete, and modify Group Policy. You’ve asked nicely, but that hasn’t had much effect. Now you want to make your point, and prevent your Domain Admins from managing Group Policy the wrong way. You decide to deny Domain Administrators the rights to modify Group Policy Objects (GPOs) through any means save the AGPM console. It may seem like a good idea, but let me explain how your time is better spent elsewhere.

    First, let’s cover the concept of a domain administrator. The domain admin is the most trusted and unrestricted user account in the domain. The domain admin can do anything in the domain and can give themselves permissions that make anything possible. The domain admin is the "Domain Overlord" if you will. Go ahead, laugh maniacally now, I’ll wait.

    The very notion that you want to deny something to a Domain Admin is a foreign concept. You don’t deny them anything. They deny rights to others. Windows and Active Directory are built upon this fundamental concept, which brings us to our next section.

    Why you’re wasting your time:

    Active Directory is tailored to Domain Admins being all-powerful. No matter what you do to restrict their rights, they can simply change it back at will. You can make it difficult, which might discourage them… but a determined admin can undo anything you change.

    You now have a new admin on the team, and during his troubleshooting “Random Group Policy Problem #5”, they receive an access denied error when managing policy through GPMC. They should be using AGPM, and the fact that they are unaware of this is a whole other issue. Most admins take access denied errors as a bad thing-- after all, they are an admin; so, they may start fixing the environment by changing permissions.

    If you contact Microsoft Support for a Group Policy related issue, we will likely return the permissions to defaults before proceeding with troubleshooting. We do not recommend this scenario, because you can't prevent a domain administrator from being an domain administrator, and your efforts can be so easily undone.

    If you modify permissions on policy folders within SYSVOL, you’re going to trigger replication for every file and folder that is changed. In large environments with many policies, that can be a significant network traffic surge.

    Most importantly, Microsoft has not tested this scenario, so you may introduce unforeseen problems to your environment by attempting it.

    What you should do instead:

    The advice I give to every customer who force domain admins into AGPM is Education. You can’t prevent a domain admin from doing something if they are determined. If you can’t trust your domain admins to do the right thing, and do it the right way, then they should not be a domain admins. That said, I suggest educating administrators by teaching them about AGPM and its benefits. Explain why they should only use AGPM manage policy, and you will likely see them consciously decide to go the extra mile to do things the correct way.

    Recently, I had a customer insist AGPM was incomplete, because it did not have this restrictive functionality built-in. The developers did not intend for AGPM to restrict admins. It was designed to provide benefits that make troubleshooting and administration of policy more manageable.

    If you’re still reading, and are determined to try this in spite of my recommendations against it:

    Editing existing Group Policy object

    During installation, in an effort to make things easier, some customers simply add the AGPM service account to the Domain Administrators group. Since we’re about to prevent domain admins from accessing production GPOs, you’ll want to read over the AGPM Least Privilege scenario and make sure you have successfully implemented this before you proceed.

    1. We’ll need to remove any Administrative users or groups from the “Group Policy Creator Owners” group. You can do this through Active Directory Users and Computers.

    2. If it’s not already there, make sure you add the AGPM service account to ”Group Policy Creator Owners”

    3. Open the Group Policy Management Console (GPMC.msc) and find the Group Policy Objects container. The Delegation tab shows a list of users/groups that have the ability to create new GPOs in the domain. You can try to remove Domain Admins from this location, but alas, it won’t let you.

    image

    Note: This is a safety feature, designed to prevent you from accidentally removing all rights to create GPOs.

    What you can do, is prevent your domain admins from editing the existing GPOs.

    4. Within GPMC, expand the Group Policy Objects container and find the Default Domain Controllers Policy.

    5. Select the Default Domain Controllers GPO and go to the Delegation tab.

    6. Remove the Domain Administrators and Enterprise Administrators groups from the delegation list.

    7. Make sure the list contains SYSTEM with full control, and ENTERPRISE DOMAIN CONTROLLERS and the Authenticated Users entries with Read permissions (at least).

    8. Repeat steps 5 through 7 for every GPO currently in your environment.

    image

    This makes your existing GPOs resistant (but not immune) to your administrator’s editorial charms.

    9. Next, open GPMC with your AGPM Administrator account and go to the AGPM console.

    10. Click on the Production Delegation tab and remove Domain Administrators and Enterprise Administrators from this location. This tab within the AGPM console determines the permissions AGPM assigns to controlled GPOs when they are deployed to production using AGPM. Making this change prevents all of the hard work you just did in the section above from going to waste.

    image

    Don’t worry that the list isn’t complete. We need to add Authenticated Users and the AGPM service account to production GPOs.

    Control Group Policy object links

    So far, we’ve removed the domain admin’s ability to edit existing GPOs, but they can still create new GPOs and link new and existing GPOs to OUs. In order to prevent these actions, we need to explicitly deny specific rights related to Group Policy.

    1. Open GPMC and click on the domain node that contains the name of your domain.

    2. Click Delegation and click Advanced.

    3. On the domain’s security dialog box, click Advanced to open the Advanced Security Settings dialog.

    4. Click Add button to add a new entry.

    5. Type Domain Admins and then click Check Names. Click OK to show the Permission Entry dialog.

    6. Click Properties.

    7. Select the Deny check box next to the permissions Write gPLink and Write gPOptions.

    8. Click OK on all dialogs until you return to GPMC.

    image

    9. Check the permissions by right-clicking the node with the name of the domain. Notice the menu items Create a GPO in this domain, and Link it here… ; Link an Existing GPO… ; and Block Inheritance are unavailable. Additionally, the menu items Enforced and Link Enabled are unavailable on existing GPO links.

    image

    10. You will need to repeat steps 1-9 for every OU in your domain. This change is also needed for any newly created OUs. It might seem easier to set these deny permissions at the domain level and let inheritance propagate the settings down to existing and new OUs, it doesn’t work. When an OU is created in Active Directory, permissions are explicitly defined at the OU level. When you set an explicit deny permission at the domain level, inheritance applies an implicit deny at the OU level. An explicit deny wins over an explicit allow; however, an explicit allow wins over an implicit deny.

    Note: There is also an option to change the default permissions applied to new OUs as they are created. This option modifies the schema, so use caution when modifying any value in the schema. The defaultSecurityDescriptor attribute is in SDDL format, so I recommend you configure one OU with the correct security settings and copy the value. This prevents having to manually set the permissions as new OUs are created in the future.

    No new GPOs for You

    So far, we removed the domain admin’s right to edit existing GPOs, and their rights to link new GPOs to existing OUs in the domain. Also, we removed their right to edit the GPOptions such as link and enforced states. The last step is to prevent a domain admin from creating new GPOs in the domain’s Group Policy Objects container.

    1. Open ADSIEdit.msc. Right-click the ADSI Edit node in the navigation pane and then click Connect to…

    2. Configure the Connections Settings dialog similar to the following image. Click OK.

    image

    3. In the navigation pane, expand the Default naming context until you find the following container: CN=Policies,CN=System,DC=domain,DC=com.

    4. Right-click CN=Policies and then click Properties.Click the Security tab.

    5. Click Advanced to open the Advanced Security Settings dialog. Add an entry for Domain Admins,and deny the permission to create or delete groupPolicyContainer objects.

    image

    This last step makes Create menu item unavailable within GPMC when creating a new Group Policy Objects. The Delete menu item remains available for GPOs; however, attempting a delete results with an access denied error.

    An Imperfect Solution:

    Many aspects of this scenario require periodic administrative attention that certainly increases management costs.. In addition, domain admins can undo this partially or in total. This can increases the difficultly that comes with troubleshooting.

    Group Policy was designed to be managed by domain administrators. Attempting to hack a solution can cause its fair share of administrative burden (even when it’s working correctly). Why? Because any domain admin can undo the solution with relative ease, making it a monumental waste of time and provides a false sense of security. Since Microsoft does not recommend this scenario, we advise everyone to use AGPM as a beneficial tool and educate your staff. When they are familiar with it, and have it as readily available as GPMC, they will be more likely to do the right thing by using the AGPM to manage GPOs.

    And the real solution? Have some consequences when admins choose not to use AGPM. That will straighten people out in a hurry. If your domain admin can't follow simples rules, like use AGPM, the imagine what other dangers lurk behind your back.

    Sean "Don't Taz Me Bro" Wright

    [Editor’s note: this was Sean’s last post – he left us for greener pastures last week. Good luck man, I hope you can get a chuckle out of your new colleagues with your famous photoshopping – Ned]

  • Friday Mail Sack: Wahoo Edition

    Hi folks, Ned here again. This week we talk GUI metadata cleanup, your useless manager (attributes), USMT abandonment and weight issues, the meaning of the DFSR nothing state, and the usual “other stuff.”

    Question

    TechNet says if you use DSA.MSC to delete a DCs computer object, the metadata cleanup process is started. Will a metadata cleanup start if you move the DC computer object from the "Domain Controllers" OU to another OU? I was reading this here "...the metadata is automatically cleaned up when a domain controller account is removed from the Domain Controllers organizational unit (OU)." 

    Answer

    You only trigger the metadata cleanup when the DC computer object is deleted. You can move it to another OU (although we really wish you wouldn’t) and cleanup won’t occur. Here I have a domain with three DCs. I move one, then I force replication between all DCs in the forest, and restart that moved DC.

    clip_image002[21]

    He’s fine afterwards – still replicating, still in the DC group, not metadata cleaned. Of course, he’s no longer applying the Default Domain Controller policy and is now getting all kinds of weird OU policy, but that’s a different problem!

    Question

    Do the manager and managedBy attributes in AD do anything, other than for the Exchange global address list info?

    Answer

    For groups, managedBy is an administrative convenience to designate “group admins”. When set like below, whatever principal listed in managedBy gets permission to update a group’s membership (the actual security is updated on the group’s AD object to allow this).

    So when you populate this:

    clip_image002

    This happens under the covers:

    image

    This is done by DSA.MSC, DSAC.EXE, and perhaps other tools; it is not some special function of the DC.

    In Win2008 and later managedBy also became the way you delegated local administration on an RODC, allowing branch admins to install patches, manage shares, etc. (http://technet.microsoft.com/en-us/library/cc755310(WS.10).aspx). 

    clip_image002[9]

    Undocumented Bonus Alert:

    On the RODC, this is updating the RepairAdmin registry value within RODCRoles:

    image

    Totally Documented Non-Bonus Not-Alert:

    You can use NTDSUTIL.EXE LOCAL ROLES to add accounts to other roles and they are stored here based on their well-known RID. See this goo.

    ManagedBy is also often used as an inventory marker by companies to denote which business unit run certain computers. It could perhaps be useful in an ADFS/Claims-aware scenario (“everyone who reports to Bob gets to access the team fantasy football league pool”), but I’ve not tried.

    I don’t know of any pure AD security usage for the manager attribute; I’ve only seen it used for the GAL and HR apps as a way to build organizational chains, like you mentioned earlier.

    Question

    The documentation on “Rerouting files and folders” mentions that the XML will migrate the contents of the source folder to the destination folder. What we have observed in our lab is that it also makes a copy of the folder’s contents in the destination folder. For instance, if I have a folder C:\TestFolder with a few files I tell USMT to migrate them to the CSIDL_PERSONAL (i.e. “My Documents”) folder of each user, it makes a copy of the contents into each user’s Documents folder and also migrates the C:\TestFolder folder to destination computer in the same c:\ location. Is this the expected behavior and is there a way to avoid the duplication?

    Answer

    This is expected, because of migdocs.xml. It is making sure the folder contents on the root of the drive are copied as part of MigXmlHelper.GenerateDocPatterns. To override this, you need additional custom XML that runs in the SYSTEM context and blocks that special folder you are redirecting to all users:

    <component type="Documents" context="System">

        <displayName>Exclude folder and override migdocs.xml</displayName>

        <role role="Data">

          <rules>

            <unconditionalExclude>

              <objectSet>

                <pattern type="File"> C:\testfolder\* [*]</pattern>

              </objectSet>

            </unconditionalExclude>

          </rules>

        </role>

      </component>

    </migration>

    That will result the testfolder contents copying to every user profile Documents folder and not copying to c:\testfolder on the destination.

    It’s very rare for anyone to do this, that’s why the behavior isn’t well documented. Mainly because it uses up a ton of additional drive space duplicating all those files. This is what miguser.xml used to do by default, which is why that XML file was deprecated – people kept running out of disk space.

    Question

    What does the DFSR replicated folder “Uninitialized” state mean? From: http://msdn.microsoft.com/en-us/library/bb540026(v=VS.85).aspx. The others seem self-explanatory or are well documented in that article.

    Answer

    State 0 (Uninitialized) has no real meaning; it is a state placeholder so that we have some point of reference instead of NULL or blank. It is expected when you first configure a replicated folder that has not yet been detected by DFSR polling due to AD replication latency or timing.

    Question

    I'm in the process of USMT customization and have run into an issue where I need to block most of a folder’s contents from migrating, but still include one specific file. This is an issue for us because we'd like to use the MigDocs.XML file - our users have a habit of storing data outside of their profiles. This particular case deals with Oracle's tnsnames.ora file located in C:\Oracle\network\admin.To use the MigDocs.XML file and not migrate C:\Oracle\*, I'd have to use an unconditional exclude. But then I wouldn't be able to migrate the tnsnames.ora file. Any suggestions?

    Answer

    This is tricky because you’re doing the opposite of what USMT was designed for (it wants to granularly exclude and grossly include). I can think of three options:

    • [Most recommended] Determine the known files/file types that exist in the oracle folder and specifically unconditionalExclude those with [sna.foo] and [*.bar], leaving only the tnsnames.ora to migrate through “omission of exclusion”. I’d imagine there aren’t too many file types in that folder and that they are fairly predictable. This also has the good side effect of not nuking any non-oracle files someone saved there in a fit of usery’ness.
    • [Sort of recommended] Use a batch file to run USMT. That batch file copies the tnsnames.ora file after you run scanstate, and puts it in the store folder. Another batch file that runs loadstate copies it out of the store folder back to that path on the destination computer.
    • [Not recommended] You can edit the actual migdocs.xml and add an explicit exclude rule in the MigDocSystem component that excludes c:\Oracle\*[*]. The two rules (implicit include generated by GenerateDocPatterns and your explicit exclude rule) have the same specificity and in that case the exclude should win. This negates the include created by GenerateDocPatterns. Now with a clean slate you can have an explicit include in another component that migrates that inner folder with the tnsnames.ora file. For example:

    clip_image002[11]

    clip_image002[13]

    clip_image002[15]

    So even though my oracle folder is like this:

    clip_image002[17]

    My actual migration store gets only this:

    clip_image002[19]

    I call this “not recommended” because it is very difficult to version control the included XML files in USMT and you end up with thousands of instances of USMT running dozens of different version of the factory XML files. Eventually, somebody screws one up, but no one knows that the default XML is now tainted. I’ve seen support cases where the customer had been troubleshooting this for weeks before they finally broken down and called us, so because of that, so I still recommend the other two options. If you go this route make sure you carefully track the edited migdocs.xml files and rename them so there is less confusion.

    If possible, use some version control software to check XML in and out – there are plenty of free ones out there or you can throw us some cash for TFS if you like what you see in the trial. There also also hosting companies that will run TFS for you, for a monthly per-seat fee, if you just want this for a project like your Windows 7 rollout. It may sound like overkill but trust me – delaying your rollout for a month because some bozo decided to monkey with the xml is not cool. You’re writing migration code, you need to treat it with the same seriousness that you’d give C++.

    Naturally, these all work for any folder/file combination. That was an awesome question.

    Oh, I just thought of a fourth option: switch to SQL server.

    Other Stuff

    Are you new to your organization, or new to the IT field? Maybe your annual review could have gone better? Here’s useful advice from Eric Brechner, an MS veteran and Principal Dev Manager; you may have read his book Hard Code. He usually only posts once a month, but each article is phenomenal, even when you disagree with him. Here’s a sample:

    The new guy
    http://blogs.msdn.com/b/eric_brechner/archive/2010/04/01/the-new-guy.aspx

    You're no bargain either
    http://blogs.msdn.com/b/eric_brechner/archive/2011/03/01/you-re-no-bargain-either.aspx

    I messed up
    http://blogs.msdn.com/b/eric_brechner/archive/2010/08/01/i-messed-up.aspx

    Individual leadership
    http://blogs.msdn.com/b/eric_brechner/archive/2011/01/01/individual-leadership.aspx

    Controlling your boss for fun and profit
    http://blogs.msdn.com/b/eric_brechner/archive/2005/08/01/august-1-2005-controlling-your-boss-for-fun-and-profit.aspx

    Superfan Mark Morowczynski points out that he already pwned the Internet before last week’s tip on using NETSH.EXE for captures, and that I owe him royalties. In lieu of money, I’ll push his blog a bit. When he can be bothered to write, he generates great stuff. Infrequent PFE bloggers are like corrupt politicians – expected, and full of excuses. Oh, and they both claim way too much on their expense reports.

    A few months back, some of us moved to a different location in the building for a project. I came to say hi, and I found this on the common area whiteboard:

    feelthelove
    All done with love, I’m sure. If the Keebler reference doesn’t make sense, go here.

    University of Virginia survived their College World Series elimination game last night, so my wife can breathe easy… until tonight, where they play the Gamecocks, who beat them on Tuesday. She’s a Wahoo Cavalier by way of graduate school. I moved to North Carolina in 2000 and found that Southerners take their college sports very seriously. When UNC loses a basketball game, my sister-in-law acts as if someone died.

    And yes, I said their. My wife tells me that no matter how long I live here, no matter how assimilated I become, no matter how many grits I eat: I will always be a damyankee. Since everyone in Chicago thinks I’m a redneck now, I have no citizenship and I’m thinking of forming my own country. I’ve already picked out my state bird:

    image
    The noble vulture

    Have a nice weekend folks.

    - Ned “carpetbag full of cookies” Pyle

  • Friday Mail Sack: Gargamel Edition

    Hi folks, Ned here again. This week we talk about 10 reasons not to use list object access dsheuristics, USMT trivia nuggets, poor man’s DFSDIAG, how to get network captures without installing a network capture tool, and some other random goo. Oh yeah, and friggin’ Smurfs.

    Question

    We’re thinking about using List Object Access dsheuristics mode to control people seeing data in Active Directory. Are there any downsides to this?

    Answer

    There are a few – here are at least ten in no particular order (thanks to PFE Matt Reynolds for some of these, although he may never realize it):

    1. This can greatly increase the number of access check calls that are made, and can have a significant negative effect on performance.
    2. This will require a huge amount of work and ongoing maintenance. You will need to create and look after – forever - selective “views” for admins, help desks, service accounts, etc.
    3. This was designed more for hosted “multi-tenant solutions” that are very specialized.
    4. Microsoft applications are not generally tested with this setting.
    5. If you can find a third party vendor that tests this, I will have a heart attack and die from shock. If you can then find a vendor that is willing to change their code if you run into problems, I will then rise from the grave and eat my own pants.
    6. It’s very difficult to test how well apps are handling this, as it’s designed to “omit data”. That could have all sorts of weird effects on apps expecting to see certain built-in or “always available” objects.
    7. Active Directory is a… directory. It’s designed to share info. Specific sensitive attribute data can always be marked confidential and that’s probably really what you want here.
    8. Doing this is one of the least useful security measures in a whole litany of things that you probably haven’t implemented – encrypting your LDAP traffic, using IPSEC everywhere, using two-factor smart cards for all user access, encrypting all drives, preventing physical removal of computers. Or making sure your web servers don’t allow ancient SQL injection attacks. Focus!
    9. This makes you unique. You don’t want to be unique.
    10. Just because you can do something does not mean you should do something. We provide an option to format your hard drive as well.

    Strangely, two people asked about this in the past few weeks.

    Question

    Can USMT perform “incremental” or “differential” scans into a store? We have a lot of data to capture and it may take awhile, especially when going to a remote store. We’d like to do it in phases if possible.

    Answer

    Sorry, no. USMT completely deletes the destination store contents when you start a scanstate (this is why you have to specify /o if the store already exists). If you perform a hardlink migration though, you are not copying data and it will scan much faster than a classic store.

    If you have to use a remote compressed classic store and you’re worried about reliability, run your scanstate to a local store location on the disk, then copy that store folder to a network location afterwards. Make sure you calculate space estimations to ensure you are not going to run out of disk, naturally.

    Question

    I don’t have any Win2008 servers – so I cannot use DFSDIAG.EXE – but I’d like to report on their DFS Namespace health. Are there other tools?

    Answer

    File Services Management Pack for System Center Operations Manager 2007
    http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14307

    That will monitor health of Win2003 DFSN very well indeed. You can also use DFSDIAG via RSAT on Vista and Win7 clients; why do I suspect that you’re looking for a more… frugal… option, though? ;-P

    The old DFSUTIL.EXE tool will stand in for DFSDIAG in a pinch, but it requires you to both run more commands and interpret the results carefully. It’s not going to spend much time explaining what’s wrong, so much as show you what it thinks is configured and let you decide if that’s wrong or not. Some of the more useful commands:

    dfsutil.exe /root:<dfs name> /view /verbose

    dfsutil.exe /server:<root server> /view

    dfsutil.exe /domain:<domain> /view

    dfsutil /sitename:<root server or dc or target or client>

    dfsutil /root: <dfs name> /sitecosting /display

    dfsutil /root: <dfs name> /insite /display

    dfsutil /root: <dfs name> /targetfailback /display

    dfsutil /root: <dfs name> /targetpriority /server:<target> /display

    dfsutil.exe /root:<dfs name> /checkblob

    dfsutil /viewdfsdirs:<volume name>

    image
    Coolish

    image
    Oops

    No complaining, we released DFSDIAG two OSes ago and you’re on a dying one. Plus we wrote it for a reason!

    Question

    The USMT hotfix KB2023591 only lists downloads for Windows 7/Windows Server 2008 R2.

    image

    Is there a version for older operating systems?

    Answer

    USMT 4.0 only cares that you run it against a client OS SKU, and that it be XP or later. The download is a CAB file and doesn’t have any OS checking for installation, only scanstate and loadstate enforce the OS. If you dig into the nugget of that main KB at the bottom you will see only:

    clip_image002

    The reason it lists the OS on the download page is it has to say something, and USMT is built from the Windows 7/R2 source tree. So there you go.

    Awesome Technique for Win7/2008 R2 Network Captures

    Not a question, but a cool method that is too small to rate a full blog post: if you need to get a network capture on a Windows 7 or Windows Server 2008 R2 computer and you do not have or want Netmon installed, you can use NETSH.EXE. From an elevated CMD prompt run:

    netsh trace start capture=yes tracefile=c:\yourcapture.etl

    Do whatever you needed to do

    netsh trace stop

    Boom – network capture, written in ETL format.

    image

    Open that file in Netmon 3.4 and you get all the usual capture info, plus other conversation and process info. AND other cool stuff – open the CAB file it created and you find a bunch of useful files with IP info, firewall event logs, applied group policies, driver versions, and more. All the goo I gather manually when I am getting a capture. Sweet!

    image

    Thanks to Tim “Mighty” Quinn for demoing this here.

    Other Stuff

    A few years ago TechNet Magazine stopped printing paper copy and switched to a web-only format. I lost track of them after that, but this weekend, I started going through their online versions from 2010 and 2011. It turns out there’s good stuff I’d been missing. Here are a few cherry picked articles; feel free to point out some other favorites in the Comments:

    Windows Confidential: Testing, Testing (Raymond Chen)
    http://technet.microsoft.com/en-us/magazine/gg675933.aspx

    An interesting explanation of what Beta used to mean, and what it means now, from a Principal SDE who has been developing Windows since the Tithonian age. Heck, his blog is ready to collect Social Security.

    Troubleshooting 201: Ask the Right Questions (Stephanie Krieger)
    http://technet.microsoft.com/en-us/magazine/ff955771.aspx

    How to be an effective troubleshooter. Don’t stop reading just because the author is an Office expert; it’s applicable across all aspects of IT. A truly excellent article that should be required reading for new admins.

    Toolbox (Greg Steen)
    http://technet.microsoft.com/en-us/magazine/ff628337.aspx?sdmr=toolbox&sdmi=columns

    Unlike me, these folks can recommend useful third party utilities. It’s a monthly column and some of these are pretty slick.

    Windows PowerShell: HTML Reports in PowerShell (Don Jones)
    http://technet.microsoft.com/en-us/magazine/hh127059.aspx

    An easy technique to take harsh text output and turn it into fluffy HTML. Perfect for punching up reporting to show your manager with zero extra effort, leaving more time for you to work on real issues. Or, you know, see your children grow up. Cat’s in the cradle and the silvaaaaah spoooon…

    Using Kerberos for SharePoint Authentication (Pav Cherny)
    http://technet.microsoft.com/en-us/magazine/ee914605.aspx

    Yes please! If you have a friend that admins SharePoint, share this with them. In fact, bribe them to follow it. Whatever it takes. NTLM is the Devil and SharePoint feeds him a jalapenos.

    image

    The Daily Mail was granted a “rare and remarkable” interview with Bill Gates last week. It’s a very interesting read.

    Remember when I said yesterday that it sucks to use the Internet in Australia and Canada? Well it sucks in other places too… The article isn’t what I’d call “complete” (it misses 98% of the world and doesn’t include my gigantic US ISP, Time Warner, for example – TW doesn’t care if I download 5 TB or 5KB, as fast and as often as I like, as long as I pay on time; I use Sprint for my phone for the very same reason – flat rate unlimited data without metering rules). A nifty piece – I recommend the comments.

    Why, Andalusia? Whyyyyyyyyyyy!?!?!?!?! I mean, I expect this from Belgium… Maybe Platformas knows.

    Have a nice weekend folks.

    - Ned “those dudes totally smurfed their smurf up” Pyle

  • Blocking Wallpaper Migration with USMT (or: you are a jerk)

    Hi folks, Ned here again. Do you hate your users? Do you revel in removing the slightest joy they have in their day? Do you wish to crush their hope and dreams, to the point of removing the small shreds of humanity they see while walled into their bleak veal pens?

    If so, this post is for you.

    Today I talk about how to block wallpaper and theme migration from Vista or Windows 7 source computers when running USMT. The actual blocking part here is trivial, so if that's all you care about skip to the end. If you want to learn something, start at the beginning: this is part of an informal series that explains USMT reverse engineering. Once you get good at this, you can figure out any weird little corner-case on your own. Even blocking default behaviors. Like not letting people have pictures of their grandkids.

    How do you live with yourself?

    Understanding how wallpaper works

    If you're migrating from Windows XP, you are already good to go - as you know from previous reading, wallpapers are not migrated automatically from that OS unless you write custom XML. However, if you are migrating from Windows Vista or Windows 7, user backgrounds do transfer over and work fine. It's tricky to turn off though, due to the shell's various personalization options. Let's walk through this.

    Here for example, looking at a Windows Vista computer, you see that the desktop key (which contains a wallpaper registry value) is migrated using an OS built-in manifest:

    C:\Windows\winsxs\Manifests>findstr /i "[wallpaper]" *.manifest

     

    x86_microsoft-windows-win32k-settings_31bf3856ad364e35_6.0.6002.18005_none_b326fbadff7217f6.manifest:

    <pattern type="Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

    A quick Internet search seems to confirm that this is the right key data, as does looking at the registry:

    image

    If you set that Win32k manifest to NO in your config.xml (which is a bad idea, as that manifest migrates quite a few other settings and the users are going to be noticeably affected), then test a migration:

    <component displayname="Microsoft-Windows-Win32k-Settings" migrate="no"

    ... the wallpaper customizations are still migrated.

    This shows the danger of searching for references in the manifests without actually looking at the rules in the XML. Let's zoom out a bit:

    <exclude>
     <objectSet
    >
      <
    pattern type=
    "Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

    Examining that manifest closely shows that it actually already blocks migration of the wallpaper setting. But if you look at an actual user migration you will see that this wallpaper registry key does migrate even with this exclusion. You can search XML all you want for this one but you will only figure it out by the process of elimination: it's coming from:

    x86_microsoft-windows-shmig_31bf3856ad364e35_6.0.6002.18005_none_6189f2a77440c81c.manifest

    … which has no rules and only runs a "SHMIG.DLL" plugin that is completely opaque to you.

    That manifest gets called by this guy in the config.xml:

    <component displayname="Microsoft-Windows-shmig" migrate="yes"

    Which is overruling the Win32K manifest. Gotta love the shell… turning that manifest off is definitely a bad idea, as it does a bazillion other things that you definitely want to migrate.

    So what to do? It turns out there are two places in the user registry settings that control the wallpaper: the wallpaper registry value in the Desktop key, and the user's custom theme:

    image
    Ahhh Vista. We hardly knew ya.

    image

    The theme encapsulates the wallpaper settings as well. That does migrate over, thanks to this component manifest:

    <component displayname="Personalized Settings" migrate="yes" ID="appearance_and_display\personalized_settings">

    <component displayname="Microsoft-Windows-uxtheme" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-uxtheme/microsoft-windows-uxtheme/settings"/>

    <component displayname="Microsoft-Windows-themeui" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui/microsoft-windows-themeui/settings"/>

    Which is the OS-supplied manifest:

    x86_microsoft-windows-themeui_31bf3856ad364e35_6.0.6000.16386_none_82c7d4771e961867.manifest

    Which only does this:

    <rules context="User">

     <include>

      <objectSet>

       <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\* [*]</pattern>

      </objectSet>

     </include>

    </rules>

    If you block the Themeui settings explicitly by using the config.xml, you block the wallpaper migration implicitly. This works because when the user first logs on and has blank theme settings, the default theme is set by the OS and voila: no customization happened, even if the Control Panel\Desktop\Wallpaper value is set. It sets the user to the default Windows theme. Sweet!

    Nevermind all that, let's block some wallpaper!

    Either of these works ion its own, pick one. The second one is the recommended one, the first one is the easier one:

    1. Use the themeui config.xml (this can have unwanted side effects for various manifests, but in this case it's atomic to wallpaper and themes) to set only this change:

    <component displayname="Microsoft-Windows-themeui" migrate="no"

    2. Use custom XML (this is a best practice and generally recommended when blocking default migration behaviors):

    scanstate c:\store /o /i:migapp.xml /i:miguser.xml /i:blockwallpaper.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <
    migration urlid="
    http://www.microsoft.com/migration/1.0/migxmlext/blockwallpaperandthemes
    ">
    <
    component type="Documents" context="User"
    >
     <
    displayName>Block Wallpaper and Themes</displayName
    >
     <
    role role="Data"
    >
     <
    rules
    >
      <
    unconditionalExclude
    >
       <
    objectSet
    >
       <!--
    Blocks wallpaper and themes (which include wallpaper) from migrating from Vista/7
    -->
        <
    pattern type="Registry">HKCU\Control Panel\Desktop [WallPaper]</pattern
    >
        <
    pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\* [*]</pattern
    >
       </
    objectSet
    >
      </
    unconditionalExclude
    >
     </
    rules
    >
     </
    role
    >
    </
    component
    >
    </
    migration
    >

    And that's it. I hope you're happy with yourself, you made that nice user cry…

    Ned "they probably had LOLCat pictures, no big loss" Pyle

  • Under One Month Before Vista SP1 Support Ends

    Hi Folks, Ned here again. Remember how a month ago, I said Vista SP1 support was ending on July 12, 2011? Well, it’s still ending on July 12, 2011. Make sure you have SP2 fully deployed or just finishing up, as we are down to the wire.

    Macht schnell!!!

    image

    - Ned “Ich spreche kein Deutsch” Pyle