Sever File and Security Migration

March 15, 2013


When migrating to a new Server, there is always the hassle of migrating files / Share and all relating security.

One the op is to start using the Microsoft File Server Migration Toolkit


Downside is that this tool is not really flexible. For example migrating sub Shares on a lower level is not possible. At least I could not do it.

So a quick fix is that golden combination !

robocopy \\SourceServer\users$\%1 d:\Users\%1 /E /V /R:0 /W:0 /COPYALL /MIR /LOG:data_copy.log

net share %1$=D:\users\%1 /GRANT:%1,FULL

Save this as a .bat file and run it with the Login User Account.

Example : Migrate.bat MyUserAccount

And it will copy the MyUserAccount folder and all the security to the D:\Users\MyUserAccount drive on the new server.

And as well create a Share with the same MyUserAccount name and give this account Full access on that share.

Enjoy !

Powershell Versions and more …

March 8, 2013

To analyze the PowerShell environment you need to dig into several framework components in order to know what you are dealing with.

First of all PowerShell is available in different flavors : 32 bit and 64 bit



It also has different releases Version 1 – 2 and 3 (at the moment)


More info you can get using these commands


The PS Version 3 adds different extra interesting modules like :

module(s) ‘ISE, CimCmdlets, PSScheduledJob, PSWorkflow, PSWorkflowUtility’

And last but not least PS accesses different versions of the .NET framework versions 1.x to 4.x

– Common Language Runtime (CLR) version

CLR 4.0.30319.296

Each version of the .NET Framework contains the common language runtime (CLR), the base class libraries, and other managed libraries.

Overview of the key features of the .NET Framework by version.

See information about the underlying CLR versions and associated development environments, and the versions that are installed by the Windows operating system.


For more info see here

Configure PowerShell to use DotNet 4.0

So if you have an Assembly that is build on a certain .NET version, and you want to use the classes in PowerShell.

You better make sure it all falls together, otherwise it won’t work.

So basically, PowerShell (the engine) runs fine under .NET 4.0. PowerShell ( the console host and the ISE ) do not, simply because they were compiled against older versions of .NET

There’s a registry setting that will change the .NET framework loaded system wide, which will in turn allow PowerShell to use .NET 4.0 classes:

reg add hklm\software\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD /d 1
reg add hklm\software\wow6432node\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD

To update PowerShell, to use .NET framework without system wide impact, because it is too tricky.

Create this powershell.exe.config in the $pshome -> C:\Windows\System32\WindowsPowerShell\v1.0 folder.

<?xml version="1.0"?> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
        <supportedRuntime version="v4.0.30319"/> 
        <supportedRuntime version="v2.0.50727"/> 

IMPORTANT : For the x64 bit you need to copy it also to the 32bit folder -> C:\Windows\SysWOW64\WindowsPowerShell\v1.0

To update just the ISE to use .NET 4.0, you can change the config ($psHome \ powershell_ise.exe.config) file to have a chunk like this:

<?xml version="1.0"?> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
        <supportedRuntime version="v4.0.30319"/> 
        <supportedRuntime version="v2.0.50727"/> 

You can build .NET 4.0 applications that call PowerShell using the PowerShell API (System.Management.Automation.PowerShell) just fine.

How to determine which CLR version an Assembly or Executable is using, you can read here :

How To Determine Which CLR Version An Assembly Or Executable Is Using

I hope this made it not more confusing, as it already was before you started reading, because it is for me 🙂