none
SmigDeploy Registry Permission Error on Source Server

    Question

  • Want to migrate my 2008R2 File server to 2012R2.  Install 2012R2 and got all roles installed including migration tools.  Copied the SMT_ws08r2_amd64 to 2008R2.  It gives me the error below when I try to register it on the source 2008R2 server.  I tried recopying it, I tried using alternative domain admin accounts.  I tried via elevated and non elevated command prompts, i tried running it from a powershell session using the ".\" method.  All with the same result.  I use server manager to manage the source so PS 3.0 is installed.  Installed .net via roles (even tried downloading standalone .net 2.0 but it says you cannot do that).  Cannot figure out why it wouldn't think i have registry permissions 

    Configuration Info.

    • Both are Virtual Machines running on 2012R2 Datacenter Failover cluster with iSCSI connections to SAN residing on same host.
    • Source File Server: 2008R2 with 300GB available on a 1TB drive, only has a C drive all shares are on it.  Running FSRM, Branch Cache, and Share and Storage Management.  No DFS, etc.  All update installed according to windows updates, don't know of any not delivered via winupdates.
    • Destination Server: 2012R2 with 1TB D drive for files, all same roles installed, all updates installed
    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    C:\Users\it.admin>cd ..
    
    C:\Users>cd ..
    
    C:\>cd SMT_ws08R2_amd64
    
    C:\SMT_ws08R2_amd64>smigdeploy.exe
    SmigDeploy.exe is checking for prerequisites.
    --------------------------------------------------------------------------------
    
    SmigDeploy.exe is registering Windows Server Migration Tools cmdlets with Window
    s PowerShell.
    
    Unhandled Exception: System.Security.SecurityException: Requested registry acces
    s is not allowed.
       at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
       at Microsoft.Windows.ServerManager.Migration.SmigDeploy.Application.RegisterP
    rerequisiteCheck()
       at Microsoft.Windows.ServerManager.Migration.SmigDeploy.Application.Register(
    )
       at Microsoft.Windows.ServerManager.Migration.SmigDeploy.Application.Main(Stri
    ng[] args)
    The Zone of the assembly that failed was:
    MyComputer
    
    C:\SMT_ws08R2_amd64>

    Saturday, April 19, 2014 5:28 AM

All replies

  • There's at least one other encounter with the same exact error message reported here. It's worth taking a look at what exactly the registry key being accessed is, and what's the error thrown. Using Process Monitor and filtering by only Registry events and powershell.exe process name would be a step in this direction. There's an article that describes using Procmon here.

    I know this isn't a quick solution, but at least additional information can be obtained. I'd also take a look in Event Viewer, in case something is written there too.

    Saturday, April 19, 2014 7:22 AM
  • Hi,

    Please post the detail error message in event log.

    Did you try to use this hotfix?

    http://support.microsoft.com/kb/2873617/en-us

    Regards.


    Vivian Wang

    Wednesday, April 23, 2014 7:26 AM
  • Vivian it is not storage server but full standard so the KB doesn't apply, i had already tried it a few days ago.  I have not been able to find an associated event log error, if you could shed light on what log those are going to maybe it is disabled.  Or if you could provide the error event numbers I could look for them, but so far I cannot find correlated event log errors.
    Wednesday, April 23, 2014 3:48 PM
  • Hi,

    Did you follow the Albert Mihai suggestion, using Process Monitor to check the result?

    Regards.


    Vivian Wang

    Monday, May 05, 2014 8:19 AM
  • No I don't have time for all that, going to simply purchase a third party program.  I'm not sure why i am surprised Microsoft migration tools never seem to work without performing alpha and beta testing for them.  The only migration tool I can think of that has ever worked for them is moving RDS CALs from one RDS server to another.
    Thursday, May 08, 2014 4:36 PM