Bonjour,
 
j'installe un DC sous 2019 dans une nouvelle forêt.
C'est un labo sous ESXi.
 
Le rôle AD pas plus tôt installé et configuré que y'a déjà un problème : l'interface réseau demeure considérée comme relevant du profil "public".
Si je redémarre le service NLA, le profil est alors bien reconnu comme relevant d'un domaine.
Après recherche, c'est un problème courant
 
Il m'a fallut configurer une dépendance pour le service NLA aux services DNS et NTDS pour qu'au reboot le profil réseau soit considéré "domaine".
 
Bon j'ai loupé un truc ou c'est encore M$ pas capable de corriger un problème ?

Hello,

J'ai ce problème sur un tout nouvel environnement en Windows Server 2019 également.

Tu saurais me dire comment tu as créé ta dépendance ?

Par contre moi je suis obligé d'arrêter le service nlasvc (qui arrête le service "Network List Service). Le service redémarre aussitot et le profil bascule bien en "DomainAuthenticated".

sc config nlasvc depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS
 
Tu peux aussi passer par la BDR : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc, clé DependOnService, ajouter les valeurs DNS et NTDS

 
Merci pour la commande.
Tu as trouvé une autre solution que ce contournement ?

Jamais eu ce souci, et je ne compte plus les DC 2019 que j'ai promu...

Malheureusement, je pense que ce n'est pas un contournement mais la correction d'un mauvais paramétrage par défaut pour le rôle AD.
Peut-être cela sera t'il corrigé à l'avenir ...
Nous n'en sommes qu'à Windows Server 2019   et le rôle AD est tellement récent  

C'est parce que t'es fort mais les forums regorgent de ce problème.

Ou pas. Quelle édition, quelle langue ? Quel niveau de patch ?
Depuis l'ISO d'éval dispo sur le site de Microsoft, même  problème ? Avec une VM sur un Hyper-V, même problème ?
 
Tu as fait une installation par défaut, ou tu as bidouillé l'OS ?
Il y a des milliers de possibilités en fait. Mais si c'était systématique ça se saurait.

ISO MS d'eval 2019 à jour sans aucune bidouille et virtualisé sous vSphere.
Testé à plusieurs reprises. Juste le rôle AD installé.

Quelle version des VMWare Tools ? Tu les as mis à jour via Windows Update ? Une nouvelle version est sortie début janvier.
Carte réseau en VMXNET3 et pas E1000 ?

Windows server 2019 standard US Core récupéré sur le site microsoft MVLS. Licence activé.
Virtualisé sur du vmware en 6.7 17167734
La carte réseau est en E1000E.
Au niveau patch microsoft je suis carré.
 
J'ai déjà eu ce problème sur le même environnement avec de l'iso d'éval microsoft.

Carte E1000 -> poubelle.
 
C'est un format totalement obsolète depuis au moins 15 ans pour les VM Windows.

ok.
faut que je regarde comment gérer le remplacement de la carte par une VMXNet tout en conservant la meme ip.

Tu n'as pas trop le choix, il faut détruire la carte réseau E1000 puis en créer une en VMXNET3 (et je conseillerai de faire ça à froid). Tu perdras bien sûr la connexion réseau le temps de l'opération, et le temps de reconfigurer l'IP sur la VM.

Je rebondis une idée si MS prévoit bientôt un niveau fonctionnel en 2019 ? Je ne trouve pas l info
J'ai un domaine à mettre à niveau si je pouvais éviter de devoir le refaire dans quelques mois

Non, il n'y a pas de niveau fonctionnel 2019, et il n'y en aura probablement pas au-delà de 2016, même avec la prochaine version de Windows Server.

Et ton "pb" n'existe que si tu as un AD avec qu'un DC ce qui ne devrait jamais exister donc c'est non pb.

 
Vmware tools 11.2.5, dernier en date, sur vSphere 7.
E1000 ou VMNETX3, même problème.
 
Mais merci de t'intéresser au problème
Et ce dernier me semble être que le service NLA démarre trop tôt dans le cas d'un DC.