After re-image it seems that the passwords are not changed,tried couple of times today Please ran diagnostics and re-image after.

NI myself as reminder to myself to take a look.

running diags.

no issues found during disk diags, running memtest.

memtest did 3 passes with no issues. i went ahead and reimaged the host again but it's not accepting ssh. is there anything you need to poke or change before i reimage?

Something weird happened during the reinstall, and the machine is unable to pick up group policy. I am going to format and reinstall and see what happens.

There is an issue in the MDT install.

Q: DO you have any idea on why this happening? Could this be related to recent changes to WDS/MDT for Windows 10?

!@#@$#@@! Yes this may be that the preinstall has to use SMBv1 which was turned off due to sec policy

Verified that the security requirements in Bug 1370238 require SMBv1 to be turned off. We may be able to force XP sp3 to use SMB v2. For now this is being back burnered per management request.

Do we have any update here? If it take to much time debugging we should also consider decomm,anyway we have only 8 machines left in this pool.

Right, 8 in the pool, one of them has drowned, and we're committed to running WinXP tests until, what, June 2018? Right now, our end-to-end time from push to WinXP tests finished is at best 7-8 hours, so if we paid attention to test results before deciding to ship, we couldn't ship an esr chemspill any faster than that. If we're willing to decomm this one, what's our actual minimum number of machines/maximum end-to-end, where we would say "no, 24/36/48 hours e2e is too much, we need more than 3/2/1 WinXP machines"?

Q/Mark, can we get SMBv1 enabled briefly so that we can re-image t-xp32-ix-004 and the 15 machines in bug 1414210? I'm not privy to 1370238, so I'm not sure if we *have* to go to SMBv2 to wrap this up.

Enabled smbv1 on both wds1 and the releng dcs and confirmed XP clients can now reach them. There was a small delay here due to firewall changes

Attempted to re-image this machine again and hit the same error as the one described in the attachment above. Any ideas? Note: Windows XP will still be needed as long as esr52 is around, so I think we should find a way to be able to re-image these machines in the mean time.

Now that the deploy is talking to the WDS server correctly I see logs. I am looking at the issue now.

Rolled back some of the compatibility settings introduced for w732 testing on DELL and HP hardware with the newer MDT work bench to an older version. This has exposed the version of bdrun in the new MDT workbench no longer supports XP. I am working on a work around now.

Tried a new re-image for t-xp32-ix-004 but I catched the same issue in xpfail.jpg. Q do you know when we will have an update here? This bug is pretty old and is blocking us on other important bugs.

When [we] decided earlier this year that we would no longer need to deploy new XP clients, we did a series of upgrades to the Windows infrastructure to help support the new moonshots. The downside is that all of that prevents us from deploying XP without recreating the old infrastructure (ie we cannot make the current versions work for XP). Given that there's a chance we'll have to support XP for slightly longer than expected (if we move ESR from 59 to 60), and possibly in MDC1, we'll keep looking at this but it's a lower priority than getting stuff migrated to the moonshots. Is there anything that this is blocking other than moving 15 w8 machines to XP?

No, this is the only bug that is blocked,only that bug also block Bug 1393774 (which we want to solve it this month), also this cause possible backlog when there are many tests running on this pool(happened few times). Also by not having the possibility of re-image the machines,other machines can become unreachable like t-xp32-ix-004 and this can become a real issue in the near future.

Actually there's significant backlog on 100% of the esr52 pushes - e2e time on a push there is 7.5 hours, so in the unlikely event that we actually waited for WinXP tests on a chemspill, this bug would add 5 hours to our turnaround time.

After a deep dive some decisions that were made to support windows 10 on the new hardware broke the XP install this originally was not an issue because security changes were blacking XP installs. I have given Fubar a few options to negotiate into the schedule. We can spin out an server to just serve XP installs, We can capture an install and revive XP in AWS ( we would have to stop all talos/GFX and clipboard tests on XP), or we could try to hack an install not using the MDT service Q

The idea of hacking an install by not using MDT service sounds promising,I'll vote for this option as long as the result will consist in having enough machines to run our tests without hit backlog and as long as the result of tests are not affected by these changes. If I can help with anything please let me know.

For the limited amount of machines we're looking at, we'll go with the hack. It's not a higher priority than getting the moonshots into production, but Q will look at getting some of this going.

On my buildduty shift I came across on this bug. I digged around and I noted that this bug blocks bug 1414210 which in turn blocks bug 1410024 which in turn blocks bugs 1413921, 1413924, 1413915, 1413918 which in turn blocks other four problem tracking bugs. So, if this bug would be fix we can try to resolve bug 1414210 and further. Could you tell me what's the current status of this bug?

I updated the bug dep tree in bug 1410024. In addition to this unblocking existing bugs, we'll want to figure out the status and work involved for xp's sake in general. Thanks for re-raising this Radu!