2 Replies Latest reply on May 16, 2014 8:27 AM by forsbergmn

    AutoDomain Upgrade Procedure

    forsbergmn

      We are currently using AutoDomain version 5.55 and we would like to start using version 5.652.  Can we simply use the same AutoDomain.ini file we are currently using with version 5.55, or will we have to run the “autodomain.vbs – configure” command and create a new configuration file?

       

      The sticky situation we are in is that the original person who configured AutoDomain in our environment no longer works for us, so we do not know exactly how it was done.  Ultimate goal is to mirror the configuration that is currently being used, but use the latest version of AutoDomain.

       

      Is there an easy way to upgrade to the latest AutoDomain release?  Can we look at the values within the AutoDomain.ini and AutoDomain.vbs to find what settings were put in place when AutoDomain was configured originally?

       

      Thank you in advance for any guidance with this.

       

      Greg

        • 1. Re: AutoDomain Upgrade Procedure

          This is a long time ago, but looking at the changes file, there were significant modifications between the 5.5 and 5.6 branches - The whole way the script launches was changed to support 64bit OSs etc.

           

          The Ini files are compatible between the versions - probably some slight feature additions in the new version. I expect they are compatible.

           

          You'll need to create a new file group etc with the new codebase - functionally things are the same, but as I say, the launcher logic in 5.6 is very different.

          • 2. Re: AutoDomain Upgrade Procedure
            forsbergmn

            Great, thanks for the info.  We’ll try using our current ini file with the new AutoDomain codebase.

             

            When I compared our current ini file (version 5.55) with the ini file included in the new version of AutoDomain (version 5.562), these were the only new functionality features available:

            ;CreateUsersInSubsetOfName=0

            ;ForcePasswordChange=False

             

            I’m thinking if we leave these as the default, it shouldn’t change the behavior too much with what we currently have.

             

            Thanks again

            Greg