This is a frequently asked question the Active Directory newsgroups, so I thought it was worth a blog post.

To determine if adprep successfully have prepared the forsest and the domain (/forestPrep and /domainPrep) look for the objects below:

CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=X (Should exist if the forest has been successfully prepared)

CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=X (Should exist in each domain that has been successfully prepared)

If you know/have the DC that adprep was executed on left, You can check those log files, they give a more detailed explanation of the adprep process. C:\Windows\debug\adprep.

In fact running adprep again can be used as a verification process, as the tool itself will notify you that the process has only been run once and doesn't need to be rerun.

By the way, it's about time to move away from Windows 2000 DCs these days J

I'm back on track in Sweden after being in the US for about a month; actually I have been working a month here already, so we continue the "Windows Vista Enterprise Project" that I'm currently completely busy with (see previous post). There still remains very much work to do, and trying to catch up with all different kind of dependences this project has to other teams inside the company i.e. DNS Team, Active Directory Team, PKI Team, Storage Team, Network Team, etc takes a lot of time.

Yesterday we did ship a first release of our Windows Vista image supporting 5 different hardware models, both x86 and x64 (that actually makes it 10) and a customized installation of Microsoft Office 2007. To certify a specific hardware model, takes about 8 hours (both x86 and x64) and then we use an 'own' developed method for certify our hardware. This is basically it (a bit simplified)

• Download all drivers for the specific model from the hardware vendor's web site.
• Create a folder structure for the specific hardware model in the central storage repository that looks something like:
  • HP nc6010p x64
    • 6010p
      • Network
      • Chipset
      • Storage
      • And so on…
    • Swsetup
      • App0Driver1
      • And so on.
• Extract the content by lunching a custom tool (wrapping around winrar.exe)
  • Identify driver type. (Core Driver) or (App0): The difference between those is that Core Driver is a REAL driver and App0 is a "BAD" driver that needs to execute some kind of setup package, i.e. .exe or .msi package.
• Check in the "REAL" drivers into the System Center Configuration Manager (Our main deployment tool) into the "All Drivers" driver package.
• Create Application Packages for all App0 Drivers.
• Create a task sequencer for the specific hardware, It will be something like "Install Vista Core-VBL-Hardware-HP6910p X86" The HW model is automatically detected by using a simple WMI query.
• Adding the App0 packages, and configures the task sequencer to use "Auto Apply Drivers" that means that Windows Vista during the deployment will do a PNP detection and by its own chose the best drivers from the "All-Drivers" driver package. We have to watch out for compatibility issues here between x86/x64 and storage drivers, It can cause Windows to never boot.
• Once the computer has finished it's deployment, We use a custom made report in System Center Configuration Manager that tells us the best matching drivers that was picked up by Windows during the install, the best matching drivers in the "All-Drivers" driver package, as well all drivers that for some reason failed to install (if any) or if a device is completely missing a driver.
• Based on this information, the drivers for the specific model is locked and the model us getting its own Driver Package, based on the report generated above, the deployment starts all over again but now with its own driver package instead of "Auto Apply Drivers",
• The process is repeated until all devices have a working driver.

It's been a very long time since I did the last blog post here. So what did happen, did I just disappeared a few weeks before Windows Server 2008 RTM. Oh no, But Windows Server 2008 RTM has been a lot of work to me and the entire company, as you may been aware of I have been responsible for putting Windows Server 2008 Pre-release code out in production at a bunch of customers, It's definitely been a lot of challenges and a lots of fun to driving this program, as well it did put a lot of value both to the customers that participated and to Microsoft – for all the great feedback we did give them, and all the bugs we did found and got resolved before the product did hit RTM. I will quote a line for the RTM announcement I received from Microsoft. "When you look at Windows Server 2008, you should think there is a little price of you in that product – thanks for helping us making this product" and I would say thanks for letting me having the opportunity to be a part of the Longhorn project. It is a few days now since I've installed the first Windows Longhorn DC back in early 2005. I would like to thank many people at Microsoft and at last, but not least Mikael Nyström (TrueSec Employee) and Anders Jansson (former TrueSec Employee) for running this program with me.

So what are I'm up to know? Did I move straight on to the next Windows version? Well in fact I did, I went on to early builds on what's next after Windows Vista/Windows Server 2008 even before Windows Server 2008 did hit RTM, but that's another story.

Let's stay with Windows Vista for a while, okay wait a sec, aren't I'm supposed to be a server guy, or more specific AD guy? O Yes I'm, don't get me wrong there. But I got very bored of all noises about Windows Vista like "There is no way you can migrate an enterprise company over to that crapy platform". Eh, if you know me you know that I'm totally are in love with large enterprise environment, the complexity, scalability issues, communication, and working across different countries, working with multiple teams. So I did decided to join and drive one of the most interesting and challenging projects I've come across so far, I happen to be in Team Platform Core:

Deploying and migrating over 60 000 clients from a mixture of Windows XP and Windows 2000 Professional with a time line of only 3 years, reaching out to 95% of all internal business units with Windows Vista SP1 and Office 2007 SP1 using System Center Configuration Manager 2007. This customer dose currently has around 10000 + applications. Oh yes they have to remain working once we switched every PC into Windows Vista form now and the coming two years. It gets even more complicated, they happen to have an industrial line that runs 24/5 around the globe.

I think we have so far done a lot of right decision in this project, and it's the best team I ever been working with, both internal and external people in this project is very skilled and professional in what they do, we definitely have the right people here. The most challenge part so far has been time, but there is no way to delay the final results of this project, you may ask why? The answer is pretty simple: End of support for Windows 2000 Professional by year 210 (most of the workstations are running at this platform today) not receiving security updates nor there is going to be any support beyond that date isn't an option for an enterprise customer like this. So we have about 2 years left, we haven't deployed a single Windows Vista PC in production yet. So if our calculations are made right. (Yes our team did get the statistics of the network performance at over 640 sites, did put together I formula for when to use a SCCM DP, SCCM Branch Office DP, SCCM Secondary Site Server, when to create an AD site, did calculate with the size of the Windows Vista Image to go over the wire (approximately 3GB) plus Office 2007 (approximately 1GB), and what we refer to as app0 (HW based apps) and app1 (core apps) as well USMT data during migration (approximately 20GB) going upstream and downstream.) Our rollout team has to migrate around 100 PCs each day in two years to be able to successfully accomplish the goal. I will report more from this project and what it is like to be in the middle of it, next post will probably be about application compatibility, what strategy we did choose, why Microsoft ACT wasn't enough, what custom tools our team did put together to in order for making it all possible for Team Application.

Fine Grain Password Policy Tool Beta 2 is ready!

Build: FGPP Beta 2_2256-20080120.1
Branch: FGPP-Beta2-branch.
Usage: In a Windows Server 2008 Test environment.

General Information

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

Download

Download Fine Grain Password Policy Tool (x86) Beta 2.
http://blogs.chrisse.se/files/folders/32/download.aspx

Download Fine Grain Password Policy Tool (x64) Beta 2.
http://blogs.chrisse.se/files/folders/33/download.aspx

Quick Start Guide
http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

System Requirements

Fine Grain Password Policy Tool (FGPP) Beta 2 are “Supported” on the following platforms

·         Windows Server 2008

·         Windows Vista and Windows Vista Service Pack 1

·         Windows Server 2003 Service Pack 1 and Windows Server 2003 R2

·         Windows XP Service Pack 2

Prerequisites

Before installing this build, you must have:

Windows Server 2008 and Windows Vista

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)

Windows Server 2003 and Windows XP

·         Microsoft .NET Framework 2.0.

·         Microsoft Management Console 3.0

·         Windows Server 2008 Active Directory Domain,

·         Windows PowerShell installed (for command-line and scripting support)

Microsoft Managemnt Console for Fine Grain Password Polices: (Click for full size)



Usage information 

Note: Use Fine Grain Password Policy at your own risk.

Note: The Fine Grain Password Policy Tool will currently only work from a domain joined computer.

Fine Grain Password Policy Tool Core PowerShell Samples.

FGPP Beta 2 Milestone (Build 2230-2258) supports the following PowerShell Commands.

Create new Password Policies
New-PasswordPolicy <Name> [-domain <FQDNDomainName>] -MaximumPasswordAge <DD.HH:MM> -MinimumPasswordAge <DD.HH:MM> -MinimumPasswordLength <PassswordMinLenght> -PasswordComplexityEnabled <$True/$False> -PasswordReversibleEncryptionEnabled <$True/$False> -PasswordSettingsPrecendence <PrecendenceOrder> -PasswordHistoryLength <NumberOfPasswords> -LockoutDuration <DD.HH:MM> -LockoutObservationWindow <DD.HH:MM> -LockoutThreshold <int> -AppliesTo *SupportedNameFormats

Modify existing Password Policies
Modify-PasswordPolicy <name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <DD.HH:MM>] [-MinimumPasswordAge <DD.HH:MM>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <DD.HH:MM>] [-LockoutObservationWindow <DD.HH:MM>] [-LockoutThreshold <int>] -AppliesToAdd *SupportedNameFormats -AppliesToRemove *SupportedNameFormats

Delete Password Policies
Delete-PasswordPolicy <name> [-domain <FQDNDomainName>] [-all]

Reame Password Policies
Rename-PasswordPolicy <name> [-domain <FQDNDomainName>] -NewName <name>

Add users and global groups to an existing Password Policy
Add-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] -AppliesTo *SupportedNameFormats

Remove users and global groups to an existing Password Policy
Remove-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] -AppliesTo *SupportedNameFormats [-all]

Get the Effective PasswordPolicy for one or more users objects
Get-PasswordPolicyEffective <name> [-domain <FQDNDomainName>]

------------------------------------------------------------------------------------------------------------------------------------

*SupportedNameFormats: [Domain\UserN, "First LastName", {4fa050f0-f561-11cf-bdd9-00aa003a77b6}, example.microsoft.com/software/user name, usern@example.microsoft.com, S-1-5-21-397955417-626881126-188441444-501]

Fine Grain Password Policy Tool Additional PowerShell Samples.

FGPP Beta 2 Milestone (Build 2230-2258) supports the following PowerShell Commands.

------------------------------------------------------------------------------------------------------------------------------------

How to use the Get-PasswordPolicy and New-PasswordPolicy to copy an existing PasswordPolicy

Note: Any parameter can be used with New-PasswordPolicy override settings from the existing policy.

Get-PasswordPolicy <name> [-domain <FQDNDomainName>] | New-PasswordPolicy <Name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <DD.HH:MM>] [-MinimumPasswordAge <DD.HH:MM>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <DD.HH:MM>] [-LockoutObservationWindow <DD.HH:MM>] [-LockoutThreshold <int> -AppliesTo * SupportedNameFormats]

------------------------------------------------------------------------------------------------------------------------------------

How to check policy compliance for linked users for a one or more Password Policies

foreach ($Policy in Get-PasswordPolicy [<Name>]) { foreach ($Applied in $Policy.AppliesTo) { Get-PasswordPolicyEffective $Applied } }

public static List<string> GetADDomainsFromCurrentForest()

List<string> domains = new List<string>();

foreach (Domain domain in Forest.GetCurrentForest().Domains)

try

catch (Exception e)

//

foreach (TrustRelationshipInformation trust in Forest.GetCurrentForest().GetAllTrustRelationships())

try

DirectoryContext context = new DirectoryContext(DirectoryContextType.Domain, trust.TargetName);

domains.Add(Domain.GetDomain(context).Name);

catch (Exception e)

//

return domains;

Fine Grain Password Policy Tool Beta 1 is ready!

Authors:
Christoffer Andersson.
Microsoft MVP – Directory Services
Executive Consultant - TrueSec

Thanks to the following people for helping me develop the Fine Grain Password Policy Tool

• Björn Österman, DGC
• Stanimir Stoyanov, AeroXperience
• Thanks to the entire TrueSec Team for all support during the development.
  

Usage: In a Windows Server 2008 Test Environment.

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

Download Fine Grain Password Policy Tool (x86) Beta 1.

Quick Start Guide: http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

System Requirements
Fine Grain Password Policy Tool (FGPP) Beta 1 are “Supported” on the following platforms

• Windows Server 2008 / Longhorn Server Beta 3
• Windows Vista
• Windows Server 2003 Service Pack 1 and Windows Server 2003 R2
• Windows XP Service Pack 2
  
  Prerequisites
  Before installing this build, you must have:
  Windows Server 2008 and Windows Vista
• Windows Server 2008 Active Directory Forest or (Schema Version 40 or later) Windows Server 2008 Beta 3.
• Windows PowerShell installed (for command-line and scripting support only)

• Microsoft .NET Framework 2.0.
• Microsoft Management Console 3.0
• Windows Server 2008 Active Directory Forest or (Schema Version 40 or later) Windows Server 2008 Beta 3.
• Windows PowerShell installed (for command-line and scripting support only)

Microsoft Managemnt Console for Fine Grain Password Polices: (Click for full size)

Manage Fine Grain Password Policies using Windows PowerShell: (Click for full size)



Use Fine Grain Password Policy Tool at your own risk.

Note: The Fine Grain Password Policy Tool will currently only work from a domain joined computer.
Note: This is the beta 1 milestone of the Fine Grain Password Policy tool. I have a lot of features coming into this tool.

Additional PowerShell Samples.
Note: FGPP Beta 1 Milestone (Build 2228) supports the following Windows PowerShell Commands.

Create new Password Policies
New-PasswordPolicy <Name>  -MaximumPasswordAge <days> -MinimumPasswordAge <days> -MinimumPasswordLength <PassswordMinLenght> -PasswordComplexityEnabled <True/False> -PasswordReversibleEncryptionEnabled <True/False> -PasswordSettingsPrecendence <PrecendenceOrder> -PasswordHistoryLength <NumberOfPasswords> -LockoutDuration <minutes> -LockoutObservationWindow <minutes> -LockoutThreshold <int> -AppliesTo *SupportedNameFormats 

Modify existing Password Policies
Modify-PasswordPolicy -Name <name> [-MaximumPasswordAge <days>] [-MinimumPasswordAge <days>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <True/False>] [-PasswordReversibleEncryptionEnabled <True/False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <minutes>] [-LockoutObservationWindow <minutes>] [-LockoutThreshold <int>] -AppliesToAdd *SupportedNameFormats -AppliesToRemove *SupportedNameFormats

Delete Password Policies
Delete-PasswordPolicy -Name <name> [-all] 

Reame Password Policies
Rename-PasswordPolicy -Name <name> -NewName

Add users and global groups to an existing Password Policy
Add-PasswordPolicy -Name <name> -AppliesTo *SupportedNameFormats 

Remove users and global groups to an existing Password Policy
Remove-PasswordPolicy -Name <name> -AppliesTo *SupportedNameFormats [-all]
-------------------------------------------------------------------------------------------------------------------------

*SupportedNameFormats: [Example\UserN, "First LastName", {4fa050f0-f561-11cf-bdd9-00aa003a77b6}, example.microsoft.com/software/user name, usern@example.microsoft.com, S-1-5-21-397955417-626881126-188441444-501]

Microsoft has introduced Snapshot Backups for Active Directory in Windows Server Longhorn Server. This feature uses the VSS API as many other Microsoft products and technologies use for the same purpose.
The snapshots can be generated/taken at anytime and can also be scheduled.
Active Directory Administrators can then mount a snapshot from a given time and browse Active Directory with the exactly same content at the given time, and perform restore individual objects. I cover Active Directory Snapshots in my 2 day course "Active Directory features in Longhorn Server" among many other new features. You can read more In detail about my lab here: http://www.truesec.com/PublicStore/product/Active-Directory-features-in-Longhorn-Server,433,147.aspx

Here is a step-by-step guide for anyone that wants to get started with Active Directory Snapshot Backups by their own now since Longhorn Server Beta 3 is released public to the web.

1. Create and mount an Active Directory snapshoot backup
   1. Type the following command at a domain controller running Longhorn Server Beta 3:
      ntdsutil and press enter. Type act inst ntds and press enter.
   2. Type snapshot and press enter, type help and review the options.
   3. To create a snapshot type the following command:
      Create and press enter, Verify that the command completed successfully.
      Note: This command can be scheduled using an at job.
   4. To mount the snapshot type the following command:
      mount <snapshot guid> and press enter.
      Note: The snapshot guid is reported by the create command output.
   5. Verify that the snapshot was successfully mounted.
      Note: Write down or memorize the path to the D:\ partition (since the database resides within that partition.
      Sample: C:\$SNAP_<TimeStamp>_VOLUMED$\
   6. Start Windows Explorer and navigate to C:\ and ensure that you can see the there mount points, and browse them.
   7. Start a new command prompt by click start click run and type cmd and press enter.
   8. Type the following to start the offline browser as a live directory services.
      dsmain –dbpath:C\$SNAP_<TimeStamp>_VOLUMED$\NTDS\ntds.dit –ldapport 345 –sslport:346 –gcport:347 –gcsslport:348 and press enter
   9. Verify that the start-up was complete.
2. Browse a snapshot backup using LDP.exe
   1. Start a LDP.exe by click start and click run and type ldp.exe and press enter.
   2. Within ldp.exe click the Connection menu and choose Connect and specify the following options:
      Server: localhost
      Port: 345
      Click the OK button.
   3. Click the Connections menu and chose Bind (or press Ctrl + B) and accept the default settings (bind as currently logged on user) and click the OK button.
   4. Click the View menu and chose Tree (or press Ctrl + T), Choose the Domain NC and click the OK button, and verify that you can browse the Domain NC from the snapshot backup.
   5. Close ldp.exe
   6. In the command prompt where you launched the DS Offline Browser (dsamian.exe) and press Ctrl + C to kill the instance, Type exit to close the command prompt.
   7. In the command prompt where you running ntdsutil with the snapshot context, type the following command:
      list mounted and press enter.
3. Dismount and delete an Active Directory Snapshot backup
   1. Type the following command to dismount the snapshot backup:
      Dismount <snapshot GUID reported by the list command above> and press enter.
   2. Type the following command to delete a snapshot backup
      delete <snapshot GUID reported by the list command above> and press enter.

    

Very impressive! It was so cool that i had to e-mail the MS Paint team at Microsoft and tell them how MS Paint is being used by customers

Format: ???
Duration: --:--

A Microsoft Employee recently posted an interesting topic about support for domain join with smart card in Windows Vista, here is the story:
 
After you require smart card interactive logon in your environment, the traditional domain join will not work because you don't have a password. Windows Vista resolves this problem by allowing domain join with smart card. However, this new feature will work only if you have Root CA certifcate on smart card.

Here is how to enroll Root CA cert on smart card:

1. Run "certutil –scroots deploy" from command line to enrollment Root CA cert

2. Run "certutil –scroots view" to verify the cert

Certutil with new scroots switch is a built-in tool in Windows Vista.

After you load Root CA cert, you will be able to select a smart card instead of username/password, and enter the PIN to join a domain.

Microsoft has decided to make the WINS Server Service available as a role for Server Core as well, this wasn't planned from the beginning but was added based on customer requests.

- WINS is now an optional feature, WINS-SC is the update name to use with ocsetup

The Server Core can now handle the following roles.

• File Server
• DHCP Server
• DNS Server
• WINS Server
• Domain Controller

The Server Core can now offer almost all infrastructure roles and makes it to the perfect optimized infrastructure server.

I have a bunch of Read-Only Domain Controllers (RODCs) running on Longhorn Core Server OS, it works really nice, and when you start thinking why should a domain controller really have a GUI at the server it self? Most people won't ever notice that the server is running "Longhorn "Server - Server Core.

- OCList.exe is a new command line tool. Running this provides the update
names for all roles and features as well as whether or not they are
installed.

If you have access to the most recent public Longhorn Server Build (December IDS) the changes above are checked in and ready to play with. FYI: The December IDS will ship with the next MSDN Subscription Media.

For more information about Server Core, Please visit the Server Core Team Blog:
http://blogs.technet.com/server_core/

Also please listen to the recent release of "The Nerd Herd". In this release be are cover Longhorn Serer Core specific. (FYI: In Swedish).
http://podradio.nu/download/22853_0.mp3

By the way this Blog Post is made directly from Microsoft Word 2007 :)