logo

 
 
 
corner left-topcorner right-top
News von Login
Immer auf dem neusten Stand
corner left-bottomcorner right-bottom

Migrating a file server including share and NTFS rights

Montag, 30 Dezember 2013

By Jim Vink

Migrating file shares can be a headache for IT administrators. The Microsoft PowerShell Migrating Tool can do the trick for you. This article descibes a step by step procedure that keeps als the share and NTFS rights in place when migrating from Windows Server 2003/2008 to Windows Server 2012.

On the Windows 2012 server:

Install via Server Manager> File and Storage Service >

  • Windows PowerShell 3.0 + ISE
  • Windows Server Migration Tool

Create Powershell files for Windows 2003 Server:

  • Open Powershell on the Windows 2012 server SmigDeploy.exe /package /architecture X86 /os WS03 /path <deploment folder path>
  • On the Windows 2003 machine, create a directory C:\MigratingTools>
  • Copy the content from Windows 2012 server naar de Windows 2003 server C:\MigratingTools\
  • Go to C:\MigratingTools and type “SMIGDEPLOY.EXE”
  • Go to C:\ MigratingTools\SMT_ws03_x86\ and doubleclick ServerMigration.pcs1

or:

Open PowerShell and type

  • Add-PSSnapin Microsoft.Windows.ServerManager.Migration
  • Get-Command -Module Microsoft.Windows.ServerManager.Migration

On the Windows 2012 Server
Open Powershell and type:

  • Add-PSSnapin Microsoft.Windows.ServerManager.Migration
  • Get-Command -Module Microsoft.Windows.ServerManager.Migration
  • Receive-SmigServerData
  • ues as password 12345678 (or any other frase)

On the Windows 2003 Server, in the open PowerShell box type the migration command:

  • Send-SmigServerData -ComputerName "NLWADVMFIL001" -DestinationPath "X:\Users" -Include All -SourcePath "F:\users" -Recurse

On the old server navigate migrate to the following key:
HKEY_LOCAL_MACHINE>SYSTEM>CurrentControlSet>Services>LanmanServer>Shares

Right click the Shares key and select “Export”, give it any name you like and save it to an area accessible from your new server.

Migrating file server incl share and NTFS rights-1

Now go to your new server, right click the registry file you have exported and select “Merge”. All your shares are now setup on your new server. If your new server uses the same drive letter then there is nothing more to do bar restart the “Server” server. Start>Run>Services.msc then restart the “Server” service. If you drive has a different drive letter to the old server then we need to do the following. On the new server, again in regedit, browse to the following key: 
HKEY_LOCAL_MACHINE>SYSTEM>CurrentControlSet>Services>LanmanServer>Shares

Now on the right hand side you can see your shares. To change the drive letter of a share simply double click the share in question and then locate the section labeled “path” and change the drive letter to the drive of your new file server as highlighted in the image below.

Migrating file server incl share and NTFS rights-2

Finally reboot the Windows 2012 Server.

If you encounter a bad performance/very slow migration check the following:

  • Check if .Net 3.5. is installed on the target server. Not a requirement but it helps!
  • Configure all the networkcards on full-duplex

Maybe you encounter delays of 5 seconds saying “ERROR 5 (0x00000005) Changing File Attributes ... Access is denied” on a lot of files. This error usually means that File/Folder permissions or Share permissions on either the source or the destination are preventing the copy. This can be caused by files downloaded from the internet and some unzipped files that have a “no copy” attribute. Stream.exe from SysInternals does the trick. Stream.exe can be download for free.

  • reset the attributes on the source servers with steams.exe –s –d driveletter\*.*
  • Instead of paths \\servername\foldername mapped the folders to a networkdrive (seems odd but it helps)
  • Changed the logging settings, skip the –verbose option.
  • Disabled Anti-Virus on the destination server
  • Use a Powershell Script to define settings

SYNTAX

Send-SmigServerData -ComputerName <string> -DestinationPath <string> -Include <All | Data | Share> -Password <SecureString> -SourcePath <string> [-Force] [-Recurse] [-Confirm] [-WhatIf] [<CommonParameters>]

For online Help about the Windows Server Migration Tools cmdlets, see http://go.microsoft.com/fwlink/?LinkId=246313 

RELATED LINKS
Online version: http://go.microsoft.com/fwlink/?LinkId=246313

PARAMETERS

-ComputerName <string>
Specifies the name or IP address of the destination server to which you want to copy data.

-DestinationPath <string>
Specifies the path on the destination server to which you want to copy data. To avoid migration failures, verify that the destination path you specify exists for share-only migration. For other migration types, verify that the path can be created on the destination computer. The path must be a valid local path. The path length cannot be longer than 246 cha racters. Wildcard characters are not supported.

-Force [<SwitchParameter>]
Overwrites existing files automatically if the files that you are migrating from the source server are newer. Also overwrites existing shares' properties if the shares' names already exist on the source server.

-Include <All | Data | Share>
Specifies the type of content to copy to the destination server. The following are acceptable values for this parameter:

  • Data: Copies only files in the folder designated by the SourcePath parameter to the folder designated by the -DestinationPath parameter. Subfolders and their content are not copied unless the Recurse parameter is added.
  • Share: Copies only the share properties assigned to the folder specified in the SourcePath parameter to the folder specified in the DestinationPath parameter. For example, if a folder was shared on the source server, it is shared on the destination server if the Share value is provided in the cmdlet, thereby preserving all share properties and permissions. Share properties for subfolders and their content are not copied unless the Recurse parameter is added. The files and subfolders in the folder designated by SourcePath are not migrated. To avoid migration failures, verify that the folder specified in the DestinationPath parameter (and all subfolders if the Recurse parameter is added) exists.
  • All: Copies both data and associated share properties.

-Password <SecureString>
Specifies the password, as a secure string, to encrypt the data transfer by using the 256-bit advanced encryption standard (AES). The secure string can be obtained by entering the command Read-Host -AsSecureString or Convertto-Securestring.

You must specify a password to protect your data because transferred data is broadcast over a network. If the Password parameter is not added to your command, you are prompted to specify a password after entering your command. The password length must be a minimum of six characters and a maximum of 260 characters.

-Recurse [<SwitchParameter>]
Copies all content of the type specified by Include parameter in the path specified in the SourcePath parameter. If this parameter is not used, subfolders of the SourcePath are not copied.

-SourcePath <string>
Specifies the folder on the source server from which you want to copy data. To avoid migration failures, it is required that you first verify that the source path you specify exists on the source computer, except in the case of share-only migration. The path must be a valid local path. The path length cannot be longer than 246 characters. Wild card characters are not supported.

-Confirm [<SwitchParameter>]
Prompts you for confirmation before executing the command.

-WhatIf [<SwitchParameter>]
Describes what would happen if you executed the command without actually executing the command.

<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type, "get-help about_commonparameters".

 

Kommentare (1)

  • Ravi Mehta

    Ravi Mehta

    28 Februar 2014 um 17:59 |
    Hi,

    Is it possible to rename the destination share but keeping the share permission and NTFS permission to the the same as the source share path ow can I achieve that ?

    Thanks for this great knowledge.

    Ravi

Sie möchten mehr Informationen rund um den digitalen Arbeitsplatz?
Dann melden Sie sich für unseren Newsletter an:

Invalid Input
Invalid Input
Invalid Input

  • loginvsi logo bw Nutanix bw Nexthink Logo SW
  • phoenix pharma logo bw moeller group logo bw RV Logo bw
  • citrix microsoft vmware
  • dachser bw isource bw Delta Lloyd bw
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Weitere Informationen Ok