Problem : New-ADUser is not working as expected to populate a password coming from a CSV file (the account stays disabled) here is the example and the reason:

Prerequisites: Import the Active Directory module on your powershell session using Import-Module ActiveDirectory

Here is my BulkAddADUsers.csv file sample :

GivenNAme,Surname,Name,SamAccountNAme,Description,Department,EmployeeID,Path,Enabled,Password,PasswordNeverExpires
User,Test1,UserTest1,UserTest1,UserTest1,IT,189478,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test2,UserTest2,UserTest2,UserTest2,IT,187516,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test3,UserTest3,UserTest3,UserTest3,IT,134530,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test4,UserTest4,UserTest4,UserTest4,IT,162455,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test5,UserTest5,UserTest5,UserTest5,IT,121901,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test6,UserTest6,UserTest6,UserTest6,IT,170221,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test7,UserTest7,UserTest7,UserTest7,IT,128669,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test8,UserTest8,UserTest8,UserTest8,IT,108705,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test9,UserTest9,UserTest9,UserTest9,IT,106381,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test10,UserTest10,UserTest10,UserTest10,IT,193922,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test11,UserTest11,UserTest11,UserTest11,IT,174066,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test12,UserTest12,UserTest12,UserTest12,IT,105871,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test13,UserTest13,UserTest13,UserTest13,IT,126670,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test14,UserTest14,UserTest14,UserTest14,IT,124671,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test15,UserTest15,UserTest15,UserTest15,IT,118935,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test16,UserTest16,UserTest16,UserTest16,IT,183367,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test17,UserTest17,UserTest17,UserTest17,IT,185662,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test18,UserTest18,UserTest18,UserTest18,IT,118972,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test19,UserTest19,UserTest19,UserTest19,IT,187421,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True
User,Test20,UserTest20,UserTest20,UserTest20,IT,167020,"OU=Test,DC=CONTOSO,DC=CA",$True,P@ssw0rd,$True

 The following command will create the users with the attributes defined above, but since the Password is not encrypted, the account will be deactivated.

[PS] C:\users\Administrator.DOMAINA\Desktop>import-CSV .\BulkAddADUsers.csv|New-ADUser

Note the AD accounts are not enabled, because the password was not taken from the CSV file, as New-ADUser requires a Secure String for the Password. Here is what you get when you try to enable it :

==>

Solution : Type a longer command line using all New-ADUser properties + the ConvertTo-SecureString commandlet

[PS] C:\users\Administrator.DOMAINA\Desktop>import-csv .\BulkAddADUsers.csv | % {New-ADUser -GivenName $_.GivenName -Surname $_.Surname -Name $_.Name -SamAccountName $_.SamAccountName -Description $_.Description -Department $_.Department -EmployeeID $_.EmployeeID -Path $_.Path -Enabled $True -AccountPassword (ConvertTo-SecureString $_.Password -AsPlainText -force) -PasswordNeverExpires $True}

Quod erat demonstrandum.

Sam

The aim of the procedure in this post is to avoid you to dig around the technet to rebuild it. It’s written for Exchange 2010 SP1 here, but can easily be adapted for any product schema updates by replacing the Exchange 2010 SP1 values and links !

AD Schema upgrade procedure with verifications (can be adapted as a general procedure by changing the Exchange 2010 SP1 references and values)

Perform Exchange server 2010 SP1 schema extension, the full procedure list is available online at http://technet.microsoft.com/en-us/library/bb125224.aspx :

1. Confirmation that the “Back-Out Plan” (see below) has been prepared.

2. Logon to the Domain Controller holding the Schema Master FSMO role using a credential that belongs to the Schema Admins security group and Enterprise Admins security group.

3. Dump the current schema into a file for comparison.  From a command prompt, run the command:  Ldifde -f Before_Schema_Update.ldf -d "cn=schema,cn=configuration,dc=domain,dc=root"

Important note : although the following step technically works, blocking AD replication by any means is not recommended, and not supported by Microsoft. As my colleague and AD expert Tanner Slayton comments (taking his words as these are complete and meaningful), Microsoft Best Practices are to test the upgrade in a Lab, ensure that a tested and well-documented Disaster Recovery plan is in place (e.g. including a detailed authoritative restore procedure of the AD to recover a previous good AD state in an unlikely case of corruption during the schema update), validate the schema extensions using Step 6. below for example, and ensure all DC's are healthy and replicating properly.

<***update**** Unsupported and not recommended... test in a lab, document DR plan, rely on this DR plan in case of schema update issue **********>

4. Ensure no replication from this Domain Controller is going to replicate to other server until Schema Extension is completed and verified:

a. Disable Outbound Replication on the server

i. At a command prompt, run the command: “repadmin /options +DISABLE_OUTBOUND_REPL” without the quotation marks.

ii. Unplug the physical network connection to ensure no communication could occur with other domain controllers.

<\***update**** Apart from the above "+disable_outbound_repl" steps and the below "-disable_outbound_repl" on Step 8., the remainder of the article remains well supported **********>

5. At a command prompt, run the command “setup /PrepareSchema” from the folder where the Exchange 2007 SP3 installation files are located.

6. If there is no error during the schema extension, then verify the current schema version. 

a. Open ADSIEdit and check the Schema version located in:

   CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC <root domain>

   Attribute: rangeUpper

   For Exchange server 2010 SP1, the value should be “14726”

b. In the same ADSIEdit session, check the ObjectVersion location in:

   CN=<your organization>, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain

   Attribute: ObjectVersion

   For Exchange server 2010 SP1, the value should be “13214”

c. Dump the current schema into a file and compare with the one obtained in step 3.  From a command prompt, run the command:  Ldifde -f After_Schema_Update.ldf -d "cn=schema,cn=configuration,dc=domain,dc=root"

d. Compare the content in the file Before_Schema_Update.ldf and After_Schema_Update.ldf to ensure proper extension is completed.  For a list of schema changes applied by Exchange server 2010 SP1 is available online at http://msdn.microsoft.com/en-us/library/dd877014(EXCHG.140).aspx

7. If the schema extension is unsuccessful or error was encountered during the extension, perform back out procedure for Schema Extension.

<***update**** Unsupported and not recommended... test in a lab, document DR plan, rely on this DR plan in case of schema update issue **********>

8. If schema extension is successful and verified

a. re-enable Outbound Replication on the server

    i. At a command prompt, run the command: “repadmin /options -DISABLE_OUTBOUND_REPL” without the quotation marks.

    ii. Re-connect the network cable

<\***update******* Apart from the "+disable_outbound_repl" steps on Step 4. and the above "-disable_outbound_repl" on Step 8., the remainder of the article remains well supported **********>

9. Force replication of Active Directory

10. Allow time for replication to be completed before execution of this step.  At a command prompt, run the command “setup /PrepareAD” from the folder where the Exchange 2010 SP1 installation files are located.

11. For every domain that you have Exchange servers deployed and users having Exchange mailboxes, run the command “setup /PrepareDomain”.

***Update: The below back-out procedure takes into account the steps used to disable replication above, which are not supported and not recommended by Microsoft any more.

Instead, the recommended Back-Out plan procedure is to have a well-documented and tested DR procedure including an authoritative restore procedure in case of AD corruption.

Back-out plan Procedure (never had to use it but it’s a parachute/belt/mattress to sleep well)

In case of incomplete schema extension or getting error during the schema extension, to avoid for any partial update of the schema to be replicated to other Domain Controllers, we must follow the steps below:

1. Power off the current Domain Controller that we’re working with, i.e. the current Schema master.

2. Go to another Domain Controller in the same domain, and seize the Schema Master FSMO role:

a. Logon to the Domain Controller using a credential that has Enterprise Administrator privilege

b. Click Start, click Run, type ntdsutil in the Open box, and then click OK.

c. Type roles, and then press ENTER.

d. Type connections, and then press ENTER.

e. Type connect to server <servername>, and then press ENTER, where <servername> is the name of the domain controller that you want to assign the FSMO role to.

f. At the server connections prompt, type q, and then press ENTER.

g. Type seize Schema Master.

h. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

3. Perform meta data clean up to remove the domain controller we use for Schema Extension, this is to ensure non partial schema extension get replicated:

a. Stay logon to the same server with the same credential as in step 2

b. Click Start, click Run, type ntdsutil in the Open box, and then click OK.

c. Type metadata cleanup, and then press ENTER.

d. At the metadata cleanup prompt, type remove selected server <ServerName> where <ServerName> is the distinguished name of the domain controller whose metadata you want to remove, in the form of cn=ServerName,cn=Servers,cn=SiteName,cn=Sites,cn=Configuration,dc=ForestRootDomain

e. To verify that the server was removed, type list servers in site, and then press ENTER. Ensure that the domain controller that you wanted to be removed is no longer displayed in the command output.

f. At the metadata cleanup: and ntdsutil: prompts, type quit.

Important:  If the domain controller that was removed was also a DNS server, ensure that references to it are removed from the Name Servers tab in the DNS console. To do this, open the DNS console using another DNS server in the domain (dnsmgmt.msc), and then click the domain name under Forward Lookup Zones. Remove any references to the domain controller that was removed from the domain.

4. Clean up all DNS record related to the old Schema Master server

5. Format the old Schema Master machine, reinstall Operating System, Reset computer account for the old server name, join back into the domain and prompt to Domain Controller and Global Catalog if that was its old configuration.

Full documentation of how to clean up the Active Directory after an unsuccessful demotion of Domain Controllers, which is similar to the situation we have here, is available online at http://support.microsoft.com/kb/216498.

To diagnose a problem more indepth, we will use the Exchange Troubleshooting Analyzer (from the Toolbox on the Exchange Management Console) :

- Select a task

- Click on trace control

- Click on set manual trace log

- On components to trace, choose Store.

- On trace tags, choose: tagQueryCi , tagQueryCiDump, and tagSearch

- Click on start tracing

- Then check the application log, once you see the event on the application log,

stop tracing.

- an MS Support Engineer will then analyze the *.etl resulting file

MS Support will then use an internal debugging tool to decrypt or transform the resulting etl file to a readable format, and analyze it and eventually give you the analyzis results.

To manage your public folders permissions, including the system folders if you still use them with Outlook 2003 clients, you no longer use PFDAVAdmin, but use ExFolders in replacement.

Some of the many new features that deserve to be underlined are :

• This can be run from an Exchange 2010 server only
• Can connect to Exchange 2010 or Exchange 2007 only, not Exchange 2003
• You can export properties of public folders and also export properties of all objects in a public folder
• Ability to connect to multiple mailbox stores at the same time to run bulk operations against multiple mailboxes across many databases at the same time

All the details and the download link are here : http://gallery.technet.microsoft.com/Exchange-2010-SP1-ExFolders-e6bfd405