6 Replies Latest reply on Apr 15, 2010 9:23 AM by peter_eepc

    Migrating Forest

      I'm looking for some advice in migrating from one Forest to anouther

       

      Currently users are on the domain "OldDomain.com" and are in a group "SAfeboot oldDomain"

       

      safeboot server is in the New Domain "NewDomain.com" but has AD connector back to "OldDomain.com", but no connector to "NewDomain.com"

       

      the Machines are all set via IP address

       

      Ad connector is set to Usernames

       

      Usernames wont be changing as part of this process

       

      we'll be using Microsofts ADMT tool to migrate users at a steady rate (over 850 users is too muych to do in one go)

       

      so where do I start?

       

      Mike

        • 1. Re: Migrating Forest

          buy some prof services ;-)

           

          I expect the connector is bound to ObjectGUID? If so you'll need to create a new connector definition to your new AD, then use something like Linkuser to migrate the bindings of the existing users to their new AD entities. 

          • 2. Re: Migrating Forest

            yes you are correct ObjectGUID.

             

            so I would Migrate the user over using ADMT (with SID Histrory) and then re-map the migrated accounts in safeboot to the new GUID of the user?

            using linkusr.vbs?

             

            is there any reason why I should not put the connector in now (im in the testing phase) our domains are way to complex to create a true Testing enviroment

             

            and yes Id love to get a contractor in but that isnt going to happen.....

             

            Mike

            • 3. Re: Migrating Forest

              if you activate the new connector, it should not create any users, because they will already exist, so yes, it's safe to do so.

               

              when you use linkuser on them, the user should move from one connector's scope to the other, so it should be fine. The connector won't create two users with the same name, well, not unless you're using a buggy version of it.

               

              As the connectors are read only though, your test environment can just be a duplicate of your EEM - that's enough to confirm the process.

              • 4. Re: Migrating Forest

                Once again thanks for the replies,

                 

                After a lot of investigation It appears that when it was originally built 60 + users had AD Connectors set.

                 

                but then for some reason the rest (2000+) have no connectors set (or none visible in Endpoint encryption manager)

                 

                the accounts have been manually created by just copying the AD Usernames and then added to the correct safeboot group in Endpoint encryption manager

                 

                so I cant see any connection with AD for these users, safeboot still works so that fine, but I now have users with AD connectors that I want to remove(the connectors)

                 

                so my new questions are

                Any pitfalls on just deleting the AD connectors?

                 

                How can I report which accounts have AD connectors and which don’t?

                 

                Once again many thanks for your time

                 

                Edders

                • 5. Re: Migrating Forest

                  Any pitfalls on just deleting the AD connectors?

                   

                  Well, changes in your AD won't be reflected to EEM anymore?

                   

                   

                  How can I report which accounts have AD connectors and which don’t?

                   

                  You can't "report" on it, but the connector log will tell you which users don't belong to it.

                   

                  If a user has no bindings for a connector, they were most likely created manually.

                  • 6. Re: Migrating Forest

                    There is SBADMCL command that reports user object binding information.

                    If you run this, it will list which users have and which ones don't have connector bindings:

                     

                    sbadmcl -command:DumpUserBinding -database:YourDatabaseName -group:UserGroupName -File:"DumpUserBinding.txt" -adminuser:SBAdmin -adminpwd:password
                    


                    Safest approach to this, is to remove user connector bindings before migration starts, then to re-add new bindings after AD migration is complete.

                    You can script all of the steps, if you deal with hundreds or thousands of user objects.

                     

                     

                    Message was edited by: peter_eepc on 4/15/10 10:23:58 AM EDT