In addition to the form logic set in the last 1.6.7 patch release, several other functions needed additional work to create and initialize local user accounts with the same name as the system hostname. This was mostly due to the inability of the system to determine the security identifier of a newly created account with the same name as the system hostname.
Is there anything particularly tricky?
Not tricky but these changes will need to be merged into version 2.0.0 before that can go live.
How should this be tested?
Create a domain user with the same name as the hostname testing the GUI version of the ADMU. Ex:
Domain User: JCADB2/JOEWORKMAN181C
Local Hostname: JOEWORKMAN181C
Attempt to migrate "JCADB2/JOEWORKMAN181C" to "JOEWORKMAN181C/JOEWORKMAN181C". The GUI should allow you to migrate the profile. The profile should successfully initialize and complete migration
Issues
What does this solve?
In addition to the form logic set in the last 1.6.7 patch release, several other functions needed additional work to create and initialize local user accounts with the same name as the system hostname. This was mostly due to the inability of the system to determine the security identifier of a newly created account with the same name as the system hostname.
Is there anything particularly tricky?
Not tricky but these changes will need to be merged into version 2.0.0 before that can go live.
How should this be tested?
Create a domain user with the same name as the hostname testing the GUI version of the ADMU. Ex: Domain User: JCADB2/JOEWORKMAN181C Local Hostname: JOEWORKMAN181C
Attempt to migrate "JCADB2/JOEWORKMAN181C" to "JOEWORKMAN181C/JOEWORKMAN181C". The GUI should allow you to migrate the profile. The profile should successfully initialize and complete migration
Screenshots