Advanced Windows PowerShell Scripting Video Training

Advanced Windows PowerShell Scripting Video Training
Advanced Windows PowerShell Scripting Video Training

Wednesday, December 9, 2015

Use DFS to Seamlessly Move Redirected Folders and Home Paths to a New Server – Part III

We are in the home stretch!

Over the past two days we have configured DFS on both Windows Server 2003 R2 and Windows Server 2012 R2. Re have replicated out data and we are now ready to start the process of decommissioning out old server.

Change the GPO to point to the new server and the new folder paths

Once you are confident that replication has occurred and completed successfully, you can now modify your GPOs to point to the new server. Clients will continue to use the old server until they are using the new GPO. The DFS Replication will make sure their data is moved to the new server.

Open Group PowerShell management Console.

In the GPO that controls the user profiles, open:

Computer Configuration à Policies à Administrative Templates à System à User Profiles

Open Set User Home Folder

Change the server in the UNC to the new server.

image

Click OK, and close the GPO.

Open the GPO that controls the file redirection

User Configuration à Policies à Windows Settings à Folder Redirection

Right click the folder where redirection is occurring and select Properties

Change the server in the UNC to the new server.

image

On folder redirection, click on the settings TAB.

Uncheck Move the contents of Documents to the new location.

image

Click OK

Click Yes

Close the GPO.

Allow plenty of time for replication to all clients. Group Policy replication is a funny thing. It is a patience driven activity. Depending on your environment, this can take hours to days. If you are in a domain with many sites, error on at least a day. Also, your clients many need to go through a few reboots before these policies take effect.

You can verify redirection on your clients. To do this, log in to a client machine as a user who would be affected by this change.

Click Start and then click File Manager

image

Right click Documents and select Properties.

Look for the location to change to the new server.

image

If this does not happen, verify that the share permissions were set correctly on the new server.

Take S1 offline and then test

Take the original server offline for a few days and make sure everything works OK.

When you are ready, bring S1 back online and allow replication to finish.

Remove DFS Replication

On S2, open the DFS Management console.

Expand Replication.

Right click UserInfoRepGroup and select Delete.

Select Yes and then click OK.

Once you are satisfied that everything is OK, you may remove DFS from S2.

Finally, this is our configuration:

image

Tuesday, December 8, 2015

Use DFS to Seamlessly Move Redirected Folders and Home Paths to a New Server – Part II

Yesterday we set of DFS on both Windows Server 2003 R2 and Windows Server 2012 R2.  Today we are going through the steps to set up our DFS Namespace and Replication so we can start the transfer of data. 

Add the DFS Namespace

On S1 (Windows Server 2013 R2), click Start à Administrator Tools à DFS Monument

Right click Namespaces and then select New Namespace.

In the Namespace Server window, type S1 and click Next

If you receive this message about the Distributed File System Service is not running, click Yes

image

In the Namespace Name and Settings window, provide the name for the namespace.  In this example, we will use UserData.

Click Edit Settings and select Administrators have full access; other users have read and write permissions

image

Click OK

Click Next

In the Namespace Type window, select Domain-based Namespace and click Next.

Click Create.

Click Close

 

Add the folder targets for both the home and the Redirected folders

Expand Namespaces and right click \\domain\UserInfo

Click New Folder

Provide the name UserHome

image

Click Add

Provide the UNC path to the shared folder for the user’s home profiles.

Click OK twice

Repeat for the redirected documents.

image

Create a replication group between S1 and S2

Go to server S2

In Server Manager click Tools à DFS Management

Right click Replication and select New Replication Group

In the Replication Group Type window, select Multipurpose Replication and click Next.

In the Name and Domain window:

                Name: UserInfoRepGroup

Click Next

In the Replication Group Members window, click Add and add in both servers.

image

Click Next

In the Topology Selection window, select Full Mesh and click Next.

Click Next in the Replication Group Schedule and Bandwidth window.

In the Primary Member window, select S1 from the drop down box and click Next.

In Folders to Replicate click Add.

(You will do this twice. Add both the home profiles and the redirected folders)

image

image

image

Click Next

On the Local Path of Home on Other Members window, you need to add a new local path for both folders on S2.

Click Edit.

Select Enable.

In the local path, enter a valid path.

image

Click OK.

You will receive this message if the path does not exists. Click Yes

image

Click Next

Repeat the process for Documents

image

Click Next

Click Create

Click Close

At this point, you must wait for a full replication. Depending on the amount of data to replicate, this can take a considerable amount of time. Be patient and do not proceed until replication completes.

This is what our configuration looks like now.

image

Tomorrow we will finish this process. We will modify our GPOs that are controlling the redirected content to focus on the new location. We will also remove the DFS replication and Namespace so we can decommission the Windows Server 2003 R2 box.

Monday, December 7, 2015

Use DFS to Seamlessly Move Redirected Folders and Home Paths to a New Server – Part I

Last week I delivered a Windows Server 2012 R2 class in Fort Wayne.  I had a real neat idea from the class pop up during the Distributed File System (DFS) content.  The class member’s situation was that he had over a terabyte of user home folders and redirected folders on a Windows Server 2003 R2 box and needed to move it to a Windows Server 2012 R2 box with minimal, if not zero, disruption to his 24-7 organization.  DFS sounds like a good idea, but would the two versions of DFS work together?

This is part 1 of a 3 part series on how we accomplished this task.

 

We started off with this configuration:

image

Our general process looks like this:

·         Install DFS Namespace and replication on both servers (S1 and S2).

·         Create a DFS Namespace on S1 that has references to both shares.

·         Create a DFS Replication Group between S1 and S2.

·         Change the GPOs to point to the new server.

·         Disable S1 and verify that the clients are using S2.

·         Bring S1 back online and remove the Replication.

·         Remove DFS from S2.

 

In all honesty, the hardest part of this was trying to remember how to install Windows Server 2003.  We struggled a bit to get it right.  I may be an MCSE on Win 2003, but it has been a very long time.  After we got the cob webs between my ears cleared up, we went to work.

 

 

Install DFS on S1 (Windows Server 2003 R2)

Insert the Windows Server 2003 R2 DVD (Or ISO file) in the DVD drive.

Click Start à All Programs à Administrative Tools à Manage Your Server.

Click Add or remove a role.

In the Configure Your Server Wizard, click Next.

On the Server Role page, click File Server à Next à Next.

In the Add File Server Role Wizard, click Next, and then click Replicate data to and from this server.

Follow any on screen instructions and then reboot the server.

 

Install DFS on S2 (Windows Server 2012 R2)

Open Windows PowerShell as an Administrator

Type (This is one continuous line):

Install-WindowsFeature -Name FS-DFS-Namespace,

    FS-DFS-Replication -IncludeAllSubFeature -IncludeManagementTools -Restart

 

Tomorrow, we will add in the DFS Namespace and replication.

 

Friday, December 4, 2015

Finding the Required Parameters in Parameter Sets

Every once and a while, a good mystery can be fun.  For IT Professionals taking a class, not so much.  During my last PowerShell class, one of my students made an observation in a help file.  The Cmdlet in question was Set-ADUser. Take a look at the help information on these two parameters.

-Identity <ADUser>
        Specifies an Active Directory user object by providing one of the following property values. The identifier in parentheses is the LDAP display name for the attribute. The acceptable values for this parameter are:
       
        -- A Distinguished Name
        -- A GUID (objectGUID)
        -- A Security Identifier (objectSid)
        -- A SAM Account Name (sAMAccountName)
       

        Required?                    true
        Position?                    1
        Default value               
        Accept pipeline input?       True (ByValue)
        Accept wildcard characters?  false

-Identity <ADUser>
        Specifies an Active Directory user object by providing one of the following property values. The identifier in parentheses is the LDAP display name for the attribute. The acceptable values for this parameter are:
       
        -- A Distinguished Name
        -- A GUID (objectGUID)
        -- A Security Identifier (objectSid)
        -- A SAM Account Name (sAMAccountName)
       

        Required?                    true
        Position?                    1
        Default value               
        Accept pipeline input?       True (ByValue)
        Accept wildcard characters?  false

 

Notice how both are “required” but we do not have to use both of them.  There is our mystery. This behavior is because they are in different parameters sets.  A parameter set is created when the author of the cmdlet adds functionality in which some of the parameters cannot be used at the same time as other parameters.  If you use a parameter that is in a parameter set other than the default set, then all the parameters that are not part of the new set are filtered out of TAB completion and the ISE intellisense. The problem is that the help files do not make note of which parameter set these parameters are a part of.  I decided to play around a little bit and create a cmdlet that uncovers this mystery.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

Function Get-RequiredParameters

{

Param (

    $Cmdlet

)

    # Get all the parameters from the source.

    $Sets = Get-help $Cmdlet -full |

    Select -ExpandProperty Syntax |

    Select -ExpandProperty SyntaxItem

 

    # Create the object template for the output.

    $Object = New-Object -TypeName PSObject -Property @{

        Set = $Null

        Parameter = $Null

        Required = $False

    }

 

    # Get the Parameter Sets from the Source

    $CMD = Get-Command -Name $Cmdlet

    $SetNames = $Cmd.ParameterSets.Name

   

    # Used to cycle through the Parameter sets

    # whiel creating the output.

    $Index = 0

 

    ForEach ($Set in $Sets)

    {

       

        $Items = $Set

       

        ForEach ($Item in $Items)

        {

           

            ForEach ($P in $Item.Parameter)

            {

                $Obj = $Object

                $Obj.Set = $SetNames[$Index]

                $Obj.Parameter = $P.Name

                $Obj.Required = $P.Required

            

                Write-Output $Obj

               

            }

            $Index++

        }

    }

<#

.SYNOPSIS

Displays all parameter Sets and the required parameters of a Cmdlet

 

.DESCRIPTION

Displays all parameter Sets and the required parameters of a Cmdlet.

This will help to clear up any confusion as to why a help files says

that a parameter is required, when it may not be.

 

.PARAMETER Cmdlet

The name of the cmdlet (or script) that you want to view the parameter

information from.

 

.Example

Get-RequiredParameters -Cmdlet Measure-object

Parameter           Required Set          

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

Property            false    GenericMeasure

Average             false    GenericMeasure

InformationAction   false    GenericMeasure

InformationVariable false    GenericMeasure

InputObject         false    GenericMeasure

Maximum             false    GenericMeasure

Minimum             false    GenericMeasure

Sum                 false    GenericMeasure

Property            false    TextMeasure  

Character           false    TextMeasure  

IgnoreWhiteSpace    false    TextMeasure  

InformationAction   false    TextMeasure  

InformationVariable false    TextMeasure  

InputObject         false    TextMeasure  

Line                false    TextMeasure  

Word                false    TextMeasure

 

Displays the parameter information for each parameter set of Measure-Object

 

.Example

Get-RequiredParameters -Cmdlet Set-ADUser | where Required -eq $True

Parameter                     Required                     Set                        

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

Identity                      true                         Identity                   

Instance                      true                         Instance

 

Displays only the parameters that are required in each parameter set,

 

.NOTES

===============================================================================

== Cmdlet: Get-RequiredParameters                                            ==

== Author: Jason A. Yoder                                                    ==

== Company: MCTExpert of Arizona                                             ==

== Date: December 3, 2015                                                    ==

== Copyright: All rights reserved.                                           ==

== Version: 1.0.0.0                                                          ==

== Legal: The user assumes all responsibility and liability for the usage of ==

== this PowerShell code.  MCTExpert of Arizona, Its officers, shareholders,  ==

== owners, and their relatives are not liable for any damages.  As with all  ==

== code, review it and understand it prior to usage.  It is recommended that ==

== this code be fully tested and validated in a test environment prior to    ==

== usage in a production environment.                                        ==

==                                                                           ==

== Does this code make changes: NO                                           ==

===============================================================================

#>

}