locked
Group Policy windows 10 Technical Preview Enterprise RRS feed

  • Pergunta

  • I was able to get machine to bind to the domain however when i try to preform gpupdate /force comes back as a DNS naming issue.

    Anyone else having this issue?

    Thank You.

    quinta-feira, 2 de outubro de 2014 13:01

Respostas

  • So I imaged the machine using a Windows 8.1 image, joined to the domain, and then ran Windows 10 as an upgrade. Group policy updates fine. There are obviously issues with changing the host name and/or joining a domain.
    • Editado Trevor Totten quinta-feira, 2 de outubro de 2014 15:43
    • Marcado como Resposta Office Dragon sexta-feira, 3 de outubro de 2014 14:49
    quinta-feira, 2 de outubro de 2014 15:42

Todas as Respostas

  • I have the same issue at work, though I'm pretty sure it worked on my home domain OK, but I'd have to check that.

    When I run a GPResult, it shows the following details:

    Computer Name: WIN-P7B3BCR59OI

    Domain: Local

    Site: (None)

    That isn't the computer name, and obviously it's on our domain, not a local workgroup. The report is titled "DOMAIN\user on WIN-P7B3BCR59OI". So it looks like there's some issue with changing the hostname. I'm going to try a reset on the machine, and join it to the domain without changing the Windows generated hostname, to see if that works OK.

    EDIT: That didn't work either.

    quinta-feira, 2 de outubro de 2014 13:19
  • I tried changing the computer name and after reviewing GPReport.html it appears user policy is applying only Computer policy is failing.

    It also shows the same thing you saw that it's not actually connecting to domain it shows the computer name and local workgroup in the report instead of the correct domain.

    quinta-feira, 2 de outubro de 2014 13:52
  • So I imaged the machine using a Windows 8.1 image, joined to the domain, and then ran Windows 10 as an upgrade. Group policy updates fine. There are obviously issues with changing the host name and/or joining a domain.
    • Editado Trevor Totten quinta-feira, 2 de outubro de 2014 15:43
    • Marcado como Resposta Office Dragon sexta-feira, 3 de outubro de 2014 14:49
    quinta-feira, 2 de outubro de 2014 15:42
  • Did you upgrade using the enterprise version?
    quinta-feira, 2 de outubro de 2014 17:56
  • Same issue for me. Did a clean install. User policy updates fine, but computer policy gives the same error that you received.

    Someone else here ran the update from 8.1, and both user and computer policy update successfully.

    quinta-feira, 2 de outubro de 2014 18:14
  • Same issue, renaming back to the one mentioned in gpresult and my computer policies work.
    quinta-feira, 2 de outubro de 2014 21:45
  • I have the same issue. I deployed the OS, using MDT 2013 scripts, from a WinPE envirnoment from Windows 8.1 Update 1, and added the DISM directory en Dism.exe 6.4, from the Windows 10 boot.wim, to service the offline image.

    The sypreped Windows 10 Technical Preview Enterprise image deployed without errors and all the drivers were injected fine, after I had updated DISM within the PE image to version 6.4. After deployment, the computer was joined to the domain with its given name. When I type hostname in the command prompt, I get back the name it was given, and that is avalable in the AD. I can login to the machine, using domain credentials, but when I run "GPRESULT /H GPReport.html", the report shows a computer name like "WIN-DSRFCODKLJK", instead of the given name. The Domain shown in the report is "local".

    I suppose this realease is not ready to be joined to a domain.


    • Editado ErikvT1 segunda-feira, 6 de outubro de 2014 09:59 incomplete
    segunda-feira, 6 de outubro de 2014 08:48
  • Same issue. I installed Enterprise version on a laptop. It got a WIN-648xxxxxx name.

    I renamed it to our naming convention and joined it to the domain.

    When I run gpresult I also see WIN-648xxxxxx as the hostname although I already renamed and rebooted the machine.

    When I turn it back in WIN-648xxxxxx it also fails applying computer settings. It just applies a few user setings.

    Some work to do. I can't test it this way in our environment.

    segunda-feira, 6 de outubro de 2014 16:11
  • I have the same issue. One thing I noticed: One the first reboot after joining the domain the PC fails to reboot, it hangs up at a black screen. If I hard power off and back on I can log in to the domain, but computer policy is not applied.

    After renaming my PC back to the auto-generated name it fails to reboot in the same way. Computer policy still fails to apply in my case.

    segunda-feira, 6 de outubro de 2014 16:38
  • Same issue, renaming back to the one mentioned in gpresult and my computer policies work.
    I tried removing the PC from the domain, rebooted, changed the name to the one listed in GPResult, rebooted again, added the domain, and rebooted yet again. Unfortunately, computer group policy still fails for me.
    segunda-feira, 6 de outubro de 2014 17:56
  • I used a Windows Server 2008r2 domain were it failed. At home I tried a Server 2012 domain. Here it does load policies with the automatic assignd computer name.
    segunda-feira, 6 de outubro de 2014 20:24
  • I have the same issue. I deployed the OS, using MDT 2013 scripts, from a WinPE envirnoment from Windows 8.1 Update 1, and added the DISM directory en Dism.exe 6.4, from the Windows 10 boot.wim, to service the offline image.

    The sypreped Windows 10 Technical Preview Enterprise image deployed without errors and all the drivers were injected fine, after I had updated DISM within the PE image to version 6.4. After deployment, the computer was joined to the domain with its given name. When I type hostname in the command prompt, I get back the name it was given, and that is avalable in the AD. I can login to the machine, using domain credentials, but when I run "GPRESULT /H GPReport.html", the report shows a computer name like "WIN-DSRFCODKLJK", instead of the given name. The Domain shown in the report is "local".

    I suppose this realease is not ready to be joined to a domain.


    I'm having the same issue here. Tired the Technical Preview Enterprise and non-Enterprise, both fresh manual builds.  I tried 2 different domains, tried one build where I did rename the PC and one where I left the default name. the GPResult always shows the domain as "local" even though I am connected to the domain.

    Hopefully there is a fix for this soon, because we can't test this very well if it isn't getting our policies. 

    terça-feira, 7 de outubro de 2014 14:45
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.
    terça-feira, 7 de outubro de 2014 18:25
  • We've got a number of machines exhibiting the same problem.  Domain join works, users can log in and user GPO applies, but the machine policy fails.  The GPRESULT shows the generated PC name and Local domain.

    Anyone from Microsoft looking at this?  From our end, this is a bit of a deal breaker for testing if we can't apply policy.  I would have to imagine anyone playing with the Enterprise edition would be much in the same boat.  We don't generally upgrade PCs, we wipe them and install an image.

    Actually, kinda hard to believe it made it to tech preview with this bug...
    quarta-feira, 8 de outubro de 2014 01:05
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.

    This worked for me aswell. Disabled TPM in BIOS resolved GPO problem.
    quarta-feira, 8 de outubro de 2014 09:16
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.

    This worked for me aswell. Disabled TPM in BIOS resolved GPO problem.
    quarta-feira, 8 de outubro de 2014 09:16
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.

    Verified as fixed for me too. I never would have expected this to matter. Thanks!
    quarta-feira, 8 de outubro de 2014 12:49
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.


    This worked for me too on a Lenovo Helix.  Disabled the "Security Chip" setting in the BIOS and now get computer and user GPOs.  Thanks.
    quarta-feira, 8 de outubro de 2014 18:29
  • More info..  disabling TPM works but is not desired since you cannot test related features.   A better solution is a TPM clear.

    Re-enable TPM (if you disabled) and go into the TPM management console via tpm.msc.   Select to clear TPM and restart.  Depending on your BIOS setting you may have to authorize the TPM clear during the subsequent post.  I now have TPM enabled for more testing...

    • Sugerido como Resposta Bob Solimine sexta-feira, 10 de outubro de 2014 15:55
    quarta-feira, 8 de outubro de 2014 21:18
  • From another thread in this forum...   disable TPM in bios resolves GPO processing and my failed Lync logons.


    This worked for me too on a Lenovo Helix.  Disabled the "Security Chip" setting in the BIOS and now get computer and user GPOs.  Thanks.

    Work too for me on Lenovo Hélix !! Thx a lot !!
    sexta-feira, 10 de outubro de 2014 14:19
  • I have home domain load it from the download iso image have not had anytrouble on the domain. can you nslookup the domain from the box. That ipv4 and ipv6 address tends be issue in join domains on computers

    sábado, 11 de outubro de 2014 19:54
  • Tried the Clear TPM and it works...  Request Clear TPM, restart and answer the BIOS screen, auto-restarts into Win10.  Win10 takes ownership of TPM when you log in.  Rerun gpupdate /force and it no longer throws the error.  gpresult /H out.html shows the correct PC name and domain.

    Just have to remember to suspend bitlocker if you have your drive encrypted as it will clear the encryption keys.  Otherwise you'll have to have your recovery keys available.  Once you restart and Win10 grabs the TPM chip, it apparently also re-enables bitlocker automatically.

    segunda-feira, 13 de outubro de 2014 22:03
  • More info..  disabling TPM works but is not desired since you cannot test related features.   A better solution is a TPM clear.

    Re-enable TPM (if you disabled) and go into the TPM management console via tpm.msc.   Select to clear TPM and restart.  Depending on your BIOS setting you may have to authorize the TPM clear during the subsequent post.  I now have TPM enabled for more testing...

    Clearing the TPM is the solution.  But this will need to be fixed in one of the upcoming builds, because this needs to be done every time you re-image the computer.  And it adds an extra manual step to an automated deployment.
    quinta-feira, 16 de outubro de 2014 19:35
  • I found that simply clearing the TPM did not work. The domain name in gpresult /h continued to show the incorrect domain even with a cleared TPM and gpupdate machine updates were unsuccessful. Instead I had to disable the TPM completely, reboot, verify the domain had updated to the correct value, verify gpupdate worked for the computer, re-enable the TPM and it seems to have stayed.

    However, DirectAccess GPO is still not being applied due to some WMI filter which I'm trying to figure out now.

    segunda-feira, 20 de outubro de 2014 23:39