Early to Plan and Early to Test Makes an Upgrade

…Intuitive, Effective, and Calm.

On Wednesday, November 17th I had the opportunity to speak to the Fort Wayne SharePoint User Group. This was the first time I have spoken to a use group, and feel over all it was a successful presentation. The title of the presentation was “Early to Plan and Early to Test, Makes an Upgrade Intuitive, Effective, and Calm.” During the presentation I spoke about the different approaches and steps to upgrading a SharePoint 2007 farm to SharePoint 2010, as a number of those in attendance are looking to begin upgrade projects during the first quarter next year.

I told those attending that I would be posting my notes and slides. I tried to format everything to include in the body of this post, but I couldn’t find a nice way to do it without hand editing a lot of HTML. (Any suggestions for a good blog editor for Word Press, I’m currently using Windows Live Writer.) Here is a link to download everything as a docx file:


Creative Commons License
Early to Plan and early to Test makes an Upgrade intuitive, effective, and calm by Scott Gillis is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at thecodeattic.wordpress.com.
Permissions beyond the scope of this license may be available at https://thecodeattic.wordpress.com/about/.


Time to Populate

This is part 3 of 4 in generating a script to populate users and groups in Active Directory. Part 3 is all about populating the groups generated with users. The first two parts are:
Part 1 Adding Users to AD Via PowerShell
Part 2 Making the Perfect Group

Step 0 – Import the Active Directory Modules:
Before we can even begin to try out commands we must make sure the Active Directory Modules have been imported. You can skip actually importing by running the predefined PowerShell prompt with Active Directory, which can be found amongst your Administrator Tools on the server. Or the old fashion way and enter the commands.
PS C:\> Import-Modules active*

Step 1 – Find out about the Command
The command which will be used is Add-ADGroupMember. The TechNet details can be found at http://TechNetMicrosoftt.com/en-us/library/ee617210.aspx.
This command allows for either groups, users, service accounts or computers to be added as members to the specified AD group. This cmdlet requires a ADGroup object, which can be returned via the -PassThru parameter when creating a new group(see part 2 for details on creating a new group) or retrieved from AD with the Get-ADGroup cmdlet.

Details on Get-ADGroup can be found on TechNet (http:TechNetMicrosoftoft.com/en-us/library/ee617196.aspx) but just like all the commands we will be needing in part 4, I am going to highlight a few of the key parameters.

Get-ADGroup returns either a single group or can return multiple groups from AD. To get more than one group returned you will have to use the Filter parameter, while to retrieve a single group you will need to provide the Distinguished Name (DN), GUID, security identifier (SID), security accounts manager (SAM) name, or the canonical name.

  • Identity
    • This parameter defines which group or groups will be returned.
    • This value can be a distinguished name, object GUID, Security Identifier (objectSID), or Security Accounts Manager Account Name (sAMAccountName)
    • This is a required parameter.
  • Properties
    • If you want additional properties outside the default set returned, these can be defined with this property.
    • This will be a comma separated list of the attributes.
    • Or you can specifyasteriskrick (*) to get all set attributes returned
    • This is an optional parameter.
    • Example: -Properties OfficePhone,Organization
  • Server
    • This defines the AD DS server which the group should be returned from.
    • Value can be Fully Qualified Domain Name, NetBIOS,Fully Qualified directory server name and port
    • If no server is given the following rules are applied to identify the server:
      1. Server value is taken from any passed in values
      2. Server from the associated with the Active Directory PowerShell provider drive
      3. The domain of the computer running PowerShell
    • This is an optional parameter

Once you hretrievedeved the AD Group object of the desired group (either via Get-ADGroup or using tPassThruThry parameter when creating a new group) it is time to begin adding members to the group. The command used to add members to a group is Add-ADGroupMember. Members that can be added are users, groups, computers, or service accounts.

New members can be identified via distinguished name (DN), GUID, security identifier (SID), SAM account name, or an AD object variable. If multiple members are to be added to the group use a coseparatedated list as the value of the Members parameter. Values parameterseres can not be submitted to Add-ADGroupMember via the pipeline,to do this use Add-ADPrincipalGroupMembership cmdlet.

The details for Add-ADGroupMember can be found on TechNet at httTechNetMicrosoftosoft.com/en-us/library/ee617210.aspx. As with the other commands, I have pulled out some of the key parameters needed for basic usage of the command.

  • Identity
    • Specifies the AD group that members will be added to.
    • This value can be a distinguished name, object GUID, Security Identifier (objectSID), or Security Accounts Manager Account Name (sAMAccountName)
    • In addition to the the above options, this value can be an AD Group object or be passed in via the pipeline.
    • This is a required parameter.
  • Members
    • A separatederated list of the members to be added to the group.
    • Members can be users, computers, groups, and security accounts.
    • This value can be a distinguished name, object GUID, Security Identifier (objectSID), Security Accounts Manager Account Name (sAMAccountName), or AD object variable.
    • This is a required parameter.
  • PassThru
    • Returns an object of the group that has just been modified.
    • By default the command returns nothing, unless this parameter is listed.
    • This is an optional parameter.
  • Server
    • This defines the AD DS server to connect to.
    • Value can be Fully Qualified Domain Name, NetBIOS,Fully Qualified directory server name and port
    • If no server is given the following rules are applied to identify the server:
      1. Server value is taken from any passed in values
      2. Server from the associated with the Active Directory PowerShell provider drive
      3. The domain of the computer running PowerShell
    • This is an optional parameter
  • Credential
    • The actions performed by the cmdlet by default use the credentials ocurrentlyrrenly logged in account running it.
    • This parameter allows for a specredentialsntials to be used to run the command. It accepts only PSCredential object
    • This is optional parameter.

Step 2 – Get and Populate a Group

Now that we have an understanding of the commands needed, lets try them out. First this to do is get the group we want to add members to.
PS C:\>$myGroup = Get-ADGroup -Identity theCoolKids
Check that you got the group
PS C:\>$myGroup = Get-ADGroup -Identity theCoolKids

With the group to add members to, it is time to add those members to the group.
PS C:\>Add-ADGroupMember -Identity $myGroup -Members myTest2Name,SQLUser,SQLAdminGroup

There we have it, how to get a preexisting group out of AD and then add new members to it. The final part of the series will be combining all of these commands into a single script to read an xml file to load Active Directory.

Making the Perfect Group

This is part 2 of my series on adding users and groups to Active Directory (AD) with PowerShell. Part 1 Adding Users to AD Via PowerShell explains the steps to add users. Users are only half the battle. I find that users are best dealt with when grouped into the perfect grouping.

Step 0 – Import the Active Directory Modules:
Before we can even begin to try out commands we must make sure the Active Directory Modules have been imported. You can skip actually importing by running the predefined PowerShell prompt with Active Directory, which can be found amongst your Administrator Tools on the server. Or the old fashion way and enter the commands.
PS C:\> Import-Modules active*

Step 1 – Learn the Command:
The command that will be used for creating groups is New-ADGroup. (A very creative name they gave it. I am slowly realizing that any task you want to perform finding the command isn’t difficult in PowerShell it is determining the correct module that is hard.) The specifics of the command can be found on TechNet (http://technet.microsoft.com/en-us/library/ee617258.aspx), but I will provide a high level review of the parameters most important to my task.

  • Name
    • The name for the group. This sets the AD Name property.
    • This is a required value.
  • GroupScope
    • Defines the scope of the group.
    • This is a required value.
    • Possible values are: DomainLocal or 0, Global or 1, Universal or 2.
    • Example: -GroupScope 1 or -GroupScope Global will both set the group scope value to global
  • Description
    • Provides a description for the group.
  • DisplayName
    • The text to be displayed for the group.
  • PassThru
    • New-ADGroup by default returns no value, this parameter causes the cmdlet to return an object of the newly created group.
  • SamAccountName
    • Defines the Security Account Manager (SAM) for the group.
  • Path
    • Defines the Organizational Unit (OU) which the group should be created in.
    • This expects a string in proper X.500 form.
    • If no value is specified the cmdlet uses the following rules to determine the OU. First, if using the AD PowerShell provider drive, the current path of the provider drive is used. Second, if the cmdlet has a default path, this will be used. Finally, if neither of these cases are true, the Path will default to the partition or naming context of the target domain.
    • -Path "OU=Users,DC=thecodeattic,DC=com"

Step 2 – Let’s make a group:
PS C:\>$myGroup = New-ADGroup -Name "theCoolKids" -GroupScope DomainLocal -Description "This is the coolest gorup of users around." -DisplayName "the very Cool Kids" -SamAccountName "theCoolKids" -PassThru

If you receive no error messages, then there is only one thing left to do. Confirm that the group was generated. Either look in AD for the group or from PowerShell enter

PS C:\$myGroup

Your result should be something similar to the following:

DistinguishedName : CN=theCoolKids,CN=Users,DC=rainfly,DC=com
GroupCategory : Security
GroupScope : DomainLocal
Name : theCoolKids
ObjectClass : group
ObjectGUID : 5cd2fe70-dbe7-4ed3-b996-546d792efd2c
SamAccountName : theCoolKids
SID : S-1-5-21-1333310011-458043100-2074871380-1138

That was fun. Part 3 will be a look at adding those users to groups.

Adding Users To AD Via PowerShell

A lot of people I am sure have written about PowerShell scripts to add new users and then automate the whole process. Many of these I have found revolve around the very nice Quest Software cmdlets, but I wanted to understand the inner workings plus generate a full script that will load users and group from a file.

This is part 1 of 4 in how to automate user creation. The steps for all four parts should work if you are directly on the server with the AD role or using Remote Server Administration Tools (RSAT) via Windows 7.

Step 1 – AD PowerShell Modules:

Before we can begin the script we need to confirm that the Active Directory modules have been loaded. At the PowerShell prompt enter: Get-Command –Module active* | Measure-Object

This command will query all loaded modules for the server which begin with ‘active’ and provide a count of what is found (| Measure-Object). Your result will look like the following if the module has not been loaded.


Your are looking for a count of 76. If you got a count of 76 or more skip on to Step 2. For the rest of us, we now need to load the AD Modules so we can write get to the fun part and write a script. At the PowerShell prompt enter: Import-Module active*
The wildcard is used again to get all those modules that are related, saves time and energy retyping each modules name. Depending on the speed of the machine you may see a green bar appear quickly at the top of the PowerShell window which shows the progress.

Perform another Get-Command –Module active* | Measure-Object to confirm that the AD Modules have loaded.


Now we are ready to begin the script.

Step 2 – Learn the Command:

The cmdlet used to add new users is New-ADUser. By using the Get-Help cmdlet you can learn the details or review the details on MSDN at http://technet.microsoft.com/en-us/library/ee617253.aspx.

Here are some of the highlights to the New-ADUser cmdlet I found most important for our script. Most of the common AD properties that you normally would set are available as parameters, any additional properties to be set can be included as part of the –OtherAttributes parameter.

As I just want some basic type users for development purposes we will not be concerned with this parameter. Parameters that we will be using are:

  • SamAccountName
    • This parameter is the Security Account Manager (SAM) value for the user created.
    • This is a required value
  • Name
    • String name to identify the new user by.
    • This is a required value.
  • AccountPassword
    • Provides the password for the new user.
    • Password setting can fail if the password does not meet the password policy restriction. The user account will still be created though.
    • This parameter requires a secure string value, this can be generated via the a separate object or entered via a prompt.
    • Example – via prompt: –AccountPassword (Read-Host –AsSecureString “password”)
    • Example – as object: $thePassword = ConvertTo-SecureString "password" -AsPlainText -Force;
  • CannotChangePassword
    • Use $false or $true
  • PasswordNeverExpires
    • Use $false or $true
    • Cannot be set true if ChangePasswordAtLogon is true
  • Description
    • Defines the description of the new user.
  • DisplayName
    • Defines the name displayed for the user.
  • Enabled
    • Use $false or $true
    • This defaults to false, so be sure to set it accordingly.
  • EmailAddress
    • The user’s email address.
  • Server
    • The domain server which should be connected to.
    • This will be defaulted when not supplied by the following: from the Server value from objects passed through the pipeline, server information with the AD PowerShell provider, domain of the computer running PowerShell
  • Path
    • This parameter is used to set the Organizational Unit (OU) or container the new user is to be added to.
    • If this parameter is not defined then the cmdlet will create the new user in the default user container for the domain.
  • PassThru
    • With this parameter the user object created is returned.

Step 3 – Tryout the Command:
Before I begin a script I like to write the single command once to make sure it behaves as I expect. So at the command prompt enter:

$thePassword = ConvertTo-SecureString "password" -AsPlainText -Force;

Then enter at command prompt:
New-ADUser -SamAccountName "myTest2SAM" -Name "myTest2Name" -AccountPassword $thePassword -CannotChangePassword $true -PasswordNeverExpires $true -Description "Test description" -DisplayName "myTest2DisplayName" -Enabled $true -EmailAddress "myTest2@rainfly.com" -Server "rainfly.com";

I just want to add a user

Working on generating some virtual development environments that run local for testing and presentations, and was in need of generating some test user accounts. So off to PowerShell I went, there will be a upcoming series on this just you wait. As I started creating new users I received the message the simple couple letter passwords did not meet the complexity defined.


(Windows cannot set the password for <user name> because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.)

What! This is a development environment for my own use, I’m not worried about it being secure. The following steps are what I discovered to change the password complexity. I do not to a lot of server administration, so there may be a faster and easier method out there, but this worked for me.

  1. Log onto the AD server.
  2. Go to Start –> Administrator Tools –> Group Policy Management
  3. This will open the Group Policy Management console
  4. Via the tree on the left navigate down to the Group Policy Objects for the domain. On the right frame right click Default Domain Policy to open the Group Policy Management Editor console.
  5. Via the tree on the left navigate: Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Account Settings –> Password Policy
  6. The right hand frame will now display all of the possible password policy settings you can change.

If you perform all of the above steps and are still receiving error messages about non-conforming passwords, the local security settings may have password policies enabled. To correct this go to Start –> Administrator Tools –> Local Security Policy.

This will open the Local Security Policy window. In the left frame, navigate the tree to Password Policy (Security Settings –> Account Policies –> Password Policy.)

You will see the same list of policy options as in the Group Manager Editor. Make the changes you want and you a user account will soon be yours.

Remember the more strict these policies are the safer you environment can be.

Big Security Hole for SharePoint Servers

You may have already read this somewhere out there, it is making the rounds across the Twitter-phere, blogs, and news. But I felt it would be important to post, or I should say re-post the issue.

Executive Summary from Vulnerability in ASP.NET Could Allow Information Disclosure (http://www.microsoft.com/technet/security/advisory/2416728.mspx)

Microsoft is investigating a new public report of a vulnerability in ASP.NET. An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config. This would allow the attacker to tamper with the contents of the data. By sending back the altered contents to an affected server, the attacker could observe the error codes returned by the server. Microsoft is aware of limited, active attacks at this time. We are actively working with partners in our Microsoft Active Protections Program (MAPP) to provide information that they can use to provide broader protections to customers. Upon completion of this investigation, Microsoft will take the appropriate action to help protect our customers. This may include providing a security update through our monthly release process or providing an out-of-cycle security update, depending on customer needs.

Scott Guthrie has an excellent post up regarding this vulnerability at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx. As normal, he has gone through with code snippets to explain the issue and what you can due to protect your systems.

Good luck keeping your systems safe!

PowerShell v2 ISE and Windows Server 2008 R2

After I have gotten my SQL Server installed, I decided the next step in building out the environment was to add some local users with different permissions for services and testing.

Instead of going through and manually clicking to add each of these new users, I decided why not learn a little more PowerShell. So the first thing I did was go to the ‘start globe’ (I know it is not the start menu, but the official/proper name escapes me plus I like the sound of ‘start globe’) and entered ‘PowerShell ISE’ in the search bar…..a few second later nothing, no results.

Since I was more concerned with developing, I went out and downloaded PowerGUI (http://powergui.org). Well, I have returned to the issue really wanting to use the built in ISE that is provided, so with some better googling I found an article on TechNet (http://technet.microsoft.com/en-us/library/dd759217.aspx) which provides an overview of the ISE for Window Server 2008 R2.

The article reviews what the PowerShell ISE is and why it is beneficial for both beginners and advance users. One of the last sentences contains the missing information I was looking for…" Windows PowerShell ISE is an optional feature." Now, I know why I couldn’t find it!!

So to get the ISE for use, the steps are simple and straight forward.

1. Open Server Manager

2. In the left-hand navigation tree select Features

a. clip_image002

3. Next click Add Features. This will launch the "Add Features Wizard"

a. clip_image004

4. Scroll down until you find Windows PowerShell Integrated Scripting Environment (ISE).

5. Click the check box and then click Next

6. Click Install

7. Now get up and do a few jumping-jacks to keep from getting leg clots, while the progress bar fills…..1…2…3…4…you can do 10, I have confidence in you.

8. Click Close once installation has finished.

9. A search for ISE now gives you two options

a. clip_image006

10. Now we can use the PowerShell ISE for development.

Now we can create scripts in a pretty environment, but what about running them. If you have just written a simple or for that matter complex script to perform some task, let’s say to write the all popular "Hello World!" to the screen. Your script might look like the following:


Now click the little green arrow or click F5. If your system is fresh the following error message most likely came up:


[For the search engine sake the message reads: File cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.]

Well, now this is a problem all we wanted to do was to greet the world from our machine….My understanding is that by default and for good reason PowerShell no matter what level user you are will not run a script that has not been digitally signed. You can run your PowerShell prompt as administrator and you will still get this message. It is a security feature to make sure you understand and know what you are about to run. This is great if you grandmother is about to run a script called ‘CatInTheCeiling.ps1’ because her friend told her it was the cutest thing in the world.

But for you and I, who actually want to accomplish some work on our development machine, this is a big slow down. We don’t want to spend the time trying to digitally sign a small PowerShell script.

The solution is quite simple, only a few steps:

1. Open a PowerShell command prompt or use the bottom window in the ISE.

2. Run this command: Set-ExecutionPolicy Unrestricted

3. Approve the warning

a. clip_image012

[For the search engine: The execution policy helps protect you from scripts that you do not trust.]

4. And you are done.

To reverse this setting use the Default option instead of Unrestricted.

For further details on the Set-ExecutionPolicy cmdlt check out its entry on MSDN at http://technet.microsoft.com/en-us/library/dd347628.aspx.