Ghost Solution Suite

 View Only
Expand all | Collapse all

GSS Migration Peer to Peer Standalone

  • 1.  GSS Migration Peer to Peer Standalone

    Posted May 21, 2007 11:59 AM
    I work in an enterprise where we have just purchased GSS.  We have 1000+ new systems that will be deployed over the next couple of years and we are looking for a standard migration system that we can roll out to contractors for our hardware rollouts.
     
    I understand that the SUM can migrate users over a network, and I can script all of this into a single package for autorun (or equivalent), but I'm looking for something a little more standalone.  We used to use a Dell system where the 2 machines would be hooked up via crossover ethernet cable and the migration would be done in this manner.  Microsoft has since bought this technology and it's no longer for sale, so we have switched to GSS.
     
     
    I could easily script to set a static IP address on the new and old machines via netsh, but i'm looking for an easier system.  Is anyone doing something similar to this?  I would like for the contractor to have a crossover cable and 2 CDs (one for the old and one for the new machine).  The ideal situation would be for them to put the CD in and hit Enter, but i understand if a little work needs to be done.  (I'm wanting to totally avoid the GUI).
     
    Any suggestions?


  • 2.  RE: GSS Migration Peer to Peer Standalone

    Posted May 21, 2007 05:02 PM
    Certainly, the user migration wizard can be run from cd or usb (without installation) in peer to peer mode from a  commandline or script. There are a couple of points to consider though.

    The migration source needs to know the name (or ip) of the migration target to establish the session. In commandline mode (if no user intervention is desired) there are various possibilities for scripting ip or name discovery and to use that item for the target.

    Secondly, to capture and restore domain users, the wizard (and hence the machine) must have a communication path to the domain (or a backup domain) where the user accounts are held.

    A different approach would be: Running the wizard from a usb key to capture user profiles from the source machine, then using the same key on the target machine to restore the profiles.

    Does the second approach meet your requirements?

    Message Edited by Xan Todd on 05-22-200710:09 AM



  • 3.  RE: GSS Migration Peer to Peer Standalone

    Posted May 21, 2007 05:10 PM
    Hi Alek,

    SUM provides you with standalone migration exe that you can use either in full UI mode or script entirely, including scripting migration between two computers. SUM remoting relies on the standard TCP connection - so long as two machines can 'talk' over TCP you can migrate p2p. It is not as comprehensive as Ghost remoting where it can connect over serial, parallel, usb cable etc.

    Now, if you are looking for semi-automated solution I would suggest that you leave original (old) machines running on the network, connect new machines to the network and run p2p mode on both. When you run SUM in scripted mode you have very little choice over what is being migrated - all you can do is to provide migration rules in the migration template. Default template that comes with SUM migrates all applications, all users, and all user files from 'user' folders (eg. my desktop, my documents, my pictures, my video etc.) You may wish to customise it - you can do this from Ghost console (create it under 'configuration resources'->'user migration templates'), then export it to SCMMigrationOptions.xml file and then copy it to 'xml' folder that you'll find under the folder that you installed SUM to. You can also manually tweak template but I suggest you use console - manual method is error prone.

    If you are looking for fully automated solution I suggest you use Ghost console. This way you do not script anything, you just create 'migration capture' task and run it. Package is automatically uploaded to your designated location on the server (or left on the client's machine). You can then create 'migration restore' task and deploy this same package to different machine. Alternatively you can automate entire process by creating a single task to capture user data, image old/new machine with standard SOE image and then restore captured user settings back to the client machine.


  • 4.  RE: GSS Migration Peer to Peer Standalone

    Posted May 24, 2007 09:01 AM
    I understand how the TCP/IP aspect works, but I want to clear up a point that Xan made.  If the machine is connected via crossover cable to the target machine, the SUM will not work because it cannot communicate with the PDC?  All of these machines will be in an active directory setting.

    Message Edited by Alek on 05-24-200706:02 AM



  • 5.  RE: GSS Migration Peer to Peer Standalone

    Posted May 28, 2007 02:17 AM
    Alek,

    Eugene and I have been investigating this.

    Are you able to tell us more about your migration process, the business reasons for keeping your contractors isolated from the network, and what local (source and target if different) and domain logon rights your contractors will be granted? This will help us understand your requirements in this area.

    Thanks,
    Xan

    Message Edited by Xan Todd on 05-28-200707:18 PM



  • 6.  RE: GSS Migration Peer to Peer Standalone

    Posted May 29, 2007 09:20 AM
    We can assume the person doing the migration will have access to local administrator rights either through domain logon or local logon.  To get into the machine, it will not need to be connected to the LAN.  As long as SUM will recognize the domain accounts and settings without being on the network, it seems that it would work.
     


  • 7.  RE: GSS Migration Peer to Peer Standalone

    Posted May 29, 2007 05:15 PM
    Hi Alek,

    We have been experimenting with capturing and restoring users when SUM is disconnected from domain. Restoring is not a big issue since all information is already captured with the package, eg. username, domain name, user SID etc. and it is reasonably easy to force domain user restoration. Obviously downside of such approach would be that if you restore users from an old domain and/or machine that is joined to a different domain - then those user profiles will become permanent waste. One will never be able to login. What's worse - some users might have personal sensitive information restored to their folders (which are now useless in the scenario above), which might become accessible to other users.
    However main problem comes during capture. If user A is logged to domain B and then disconnected itself from domain B, then no problem will exist for that user. SUM can query username and domain and compare it with user SID. However for users that are not currently logged in but are from the same domain and exist on this same machine, there simply exist no way to query domain for those users even though username and SID can be gotten. So SUM will have no way of tying those users to domain B.
    We are looking at this issue but it appears that Windows provides full info only for the users that are currently logged in, unless of course machine is physically connected to domain B and SUM can query users credentials from domain authority.
    Is it possible for example to provide your contractors with limited domain account that can only query information from domain but has no access rights to network resources and at the same time to have admin rights on local machine?


  • 8.  RE: GSS Migration Peer to Peer Standalone

    Posted May 29, 2007 07:27 PM
    Adding to Eugene's comments about capture and restore when disconnected from the domain.

    The situation identified by Eugene in the first paragraph can be mitigated by including only users from the desired domain. In GUI mode these can be selected visually. For command line migration you can specify a domain filter in the migration template xml file.

    I'd also like to clarify a comment made about security. The correct security is maintained where domain user restoration is forced.

    To obtain domain information about a particular user, at present, we use a windows api called LookupAccountSid. The reason we use this function is to ensure that accounts which have been deleted from the domain or local machine are not included in the capture. Although for domain accounts, this information must be obtained from the domain - windows does cache this information locally. The call to LookupAccountSid will initially cause the local sid cache to be checked. If the entry required is not present, the call goes out to the domain.

    If you have entries for all domain users in the local sid cache - no problem.

    Various workarounds are possible to populate the windows sid cache with the required users prior to disconnection from the domain and prior to the capture process.

    Eugene identifies two:
    a) Log on as the user you wish to migrate and perform the capture in that context
    b) Log on/log off as each user you wish to migrate (this populates the sid cache), then log on as an administrator and perform the capture

    There are also a couple more:
    c) Start the wizard and advance to the Users page (this populates the windows sid cache), then disconnect from the domain, and perform the capture.
    d) For commandline capture create a minimal template in order to cause virtually nothing to be captured, then execute (this populates the sid cache), then disconnect from the domain and perform the capture.

    I'd also guess it is possible to create a script to populate the cache independently without these workarounds. I've yet to try that.

    As an aside, I've read opinion that suggests the windows sid cache life is about 5 minutes. Experimentation indicates this is longer.  Other opinion indicates the cache has a maximum number of entries. I'd guess this to be fairly high, but it is something to bear in mind.

    Back to the problem at hand. From your previous post I'd guess that granting your contractors access to the domain as administrator isn't actually a problem in your environment. Is there any barrier to utilizing a portable mini-hub to connect both source and target machines to the network at the same time?

    Another possible method is to capture the user data to an encrypted package stored on the network, then plug in the new machine and restore the data from there.

    Thanks for your input on this one. We really appreciate it.

    Regards

    Xan
















  • 9.  RE: GSS Migration Peer to Peer Standalone

    Posted Jun 04, 2007 06:23 PM
    Somewhere in that pointy headed discussion we forgot to mention you will require a special build with the ability to force the restore of domain users where the domain is not present. Please contact us if you need it.

    -Xan


  • 10.  RE: GSS Migration Peer to Peer Standalone

    Posted Jun 07, 2007 10:38 AM
    I just wanted to chime in with my progress on this.  I've actually been taken off the project and it has been sent to our network operations group, but I wanted to continue the conversation, because I find a challenge entertaining.
     
    Xan, will these special build also allow you to pull settings from a domain account without contacting the domain?
     
    Here is the setup that I had.  I would hook two machines together via crossover cable.  I have a batch file for each computer located on a USB fob.
     
    The script for the SOURCE machine:
     

    Code:

    netsh interface ip set address local static 192.168.250.1 255.255.255.0SUM\Sumwizard.exe /target:192.168.250.2 /password:"password"


     

    And the script for the DESTINATION machine:

    Code:

    netsh interface ip set address local static 192.168.250.2 255.255.255.0SUM\Sumwizard.exe /receiver /password:"password"


     
    The SUM GUI does not seem to be picking up the domain users at all with this setup.

    Message Edited by Alek on 06-07-200708:15 AM



  • 11.  RE: GSS Migration Peer to Peer Standalone

    Posted Jun 07, 2007 04:40 PM
    Alek,

    SUM is able to capture domain users one either of two conditions:
    1. machine is connected to domain
    2. machine has cached last domain user login credentials but is not connected to domain

    Other than those two conditions there is known way to match user id (SID) to username and domain. Username and SID is the only two things that SUM has hence why it needs to contact the domain to verify whether this user is a domain user (domain in a broader scope also means "this machine"). SUM will try either "this machine" and connected (or cached) domain. If either of them returns matching SID then this is how domain relationship is established (local or domain A).

    It is easier on restore side (and we can provide you with trial build) because on the restore side we have got domain name, user name and SID all stored in a package and even though we have no domain connecttion we can still create users/profiles. We chose not to do so in the release version because if we restore domain user and domain has been migrated to a new domain - you have a very dead profile and potentially security problems on your hands of user A files accessible to user B on the new machine.

    Coming back to your question. Once you logged in, disconnect yourself from domain, connect via crossover cable and you should be able to capture domain users. However to restore those users you will require new trial build.