@iainbrighton - I'm not sure - I only found out tonight (thanks @Indhukrishna).

I just implemented it for xADCSDeployment Integration tests (dsccommunity/ActiveDirectoryCSDsc#19) so that AppVeyor.yml installs ADCS components and restarts the server, then tests execute. Seems to work fine.

Not sure whether or not it will manage if the LCM reboots the node though. I have a feeling restarts are only supported if they occur in the install: step of the AppVeyor pipeline. But worth investigating.

But in theory, this may allow tests to install AD features, promote a DC, perform the restart and then execute integration tests on the xADComputer, xADUser etc.

I have thought about this some more and this might still not be possible.

The problem is that AppVeyor must execute the text under a local account context when it first starts. However, after a test runner machine is promoted to a DC the local account context will no longer exist (domain context only). So depending on how AppVeyor logs into the machine once it has rebooted after the promotion, the next stage may fail because:

1. Unlikely that Domain context Administrator account will have the same password as Local context Administrator
2. AppVeyor may specify .\ local username context when logging in. It is possible that it specifies no context in which case we would only need to ensure the Administrator account password in the Domain context matched the Local Administrator account password.

@PlagueHO I guess we can, but try it?!

@iainbrighton - gets my vote. I'll try and spare some time this weekend to do a POC.

@PlagueHO I happened to have tried this in Ansible just now (using DSC resources to do the AD join because I'm lazy 😄). Prior to AD promoition, I had two admin accounts - the built in local admin & a local vagrant user with admin rights. My Ansible-ised DSC snippet looks like this;

- name: Install AD
  win_dsc:
    resource_name: xADDomain
    DomainName: "{{ addc_domainname }}"
    DomainNetBIOSName: "{{ addc_domainnbtname }}"
    DomainAdministratorCredential_username: "{{ addc_domainadmin }}"
    DomainAdministratorCredential_password: "{{ addc_domainadminpw }}"
    SafemodeAdministratorPassword_username: "{{ addc_safemodeadmin }}"
    SafemodeAdministratorPassword_password: "{{ addc_safemodeadminpw }}"
    module_version: "{{ addc_xactivedirectoryver }}"
  register: InstallAD

The built in local admin account must meet AD password complexity requirements otherwise the upgrade will fail, however other local accounts don't have to.

Post promotion the local vagrant user continues to work, and better yet, using the local context (i.e. ".\vagrant", in my case). I could still log in using the vagrant user even though password complexity was not met. Test machine was Win2016.

A 'whoami' shows I am logged in with a domain admin account. Looking promising!

@kewalaka Nice! It sounds like this could work! Very keen to get some great test automation in for this module.

Since AppVeyor only support a reboot during the init stage, it will not work running integrations tests in AppVeyor. I'm working on instructions how to set up a Hyper-V private environment to be able to run integration tests manually.

I'm aiming at using PowerShell Direct in this first round. It will be one of ways to set it up, we need to work on alternatives too.

My plan is that the manual testing environment will support testing multiple domain controllers for larger scenarios. But one step at a time.