Target/Pilot and Reference/Production names are confusing and not consistently referenced in the tool about aadconnectconfigdocumenter

[NileshGhodekar]

Hi @dbird03, yes I know it's very confusing initially, but this is the terminology used since the FIM product and for good reasons. I think most of the confusion seems to stem from the fact that when reading the instructions or using the terms, people miss the fact that the tool does not talk or care about "servers" but only the "configuration files" and these two terms get especially counter intuitive in case of Swing migration. So if you read the instructions keeping firmly in the mind that it talks about "config", then Target config is the to-be config that is your target/destination. and Reference config is the as-is or baseline config. The meaning of Pilot config and Production config will be clearer too given that you are supposed to promote any changes you have tested in your Dev/Test/Pilot to Production and never the other way round. As for the swing migration, if you talk in terms of config instead of servers, you'd realize what your "target config" should be what you exported from your old server. The swing migration is clearly documented in the ReadMe file as in this special case, it is counter intuitive when you think about "server" as the destination instead of "config" is what tool is treating as the destination. Hope this helps.

[dbird03]

@NileshGhodekar, thank you for your explanation on this. In my swing migration thought process, $NewServer starts as a Pilot server when Azure AD Connect is initially installed on it and configured for staging mode, then $NewServer gets promoted to Production after any necessary changes are made. Since $OldServer is currently our active server, I considered it to be the Production server. It didn’t make sense to me to refer to it as the Pilot server since I associate Pilot with testing environments that have never been used for Production. I understand now after reading your explanation that the tool is referring to the configuration files and not the servers. I’ll have to remember that $OldServer “becomes” the Pilot in a swing migration because its configuration files need to be pushed to $NewServer so $NewServer can become Production. If I ever forget, I’ll have this Issue thread to refer to haha. :)