J'ai un petit souci.
 
Je prépare un nouveau domaine en 2012 R2 (j'ai déjà mes deux DC qui fonctionnent avec users et groupes). Je souhaite utiliser comme source de mise à jour un serveur WSUS local qui est sous 2003R2. Ce serveur local est un réplica d'un serveur national, donc je n'ai pas la main sur la configuration.
 
Les PC clients actuels (sur le même domaine que le WSUS 2003R2) touchent bien le WSUS. Ces nouveau serveurs 2012R2 n'arrivent pas à dialoguer avec le WSUS. Domaine différent. Je suis sûr de l'IP de mon WSUS. QUand je vais dans la console sur le serveur en question, pas de nouveau client en 2012R2. Est-ce parce que c'est du au fait que le WSUS ne recevrait pas les mises à jour pour le nouveau système ? J'en doute, mais bon ...

Plein de raisons, notamment côté Kerberos. la façon dont sont configurés les remontées WSUS (GPO ou autre), la version de WSUS, la façon dont tu as créé tes machines...
De toute façon WSUS 2003 R2 ne sera plus supporté dans 1 an.

essai de faire un diagnostique avec ça :
 
https://www.microsoft.com/en-us/dow [...] x?id=30827

Alors, plus d'infos :
- le serveur WSUS est sur une machine 2003R2 et est bien en SP2.
- c'est un relai d'un serveur national (je ne gère donc aps les produits, juste les langues).
- les produits sont bien poussés par le national et dns le relai local (à priori).
- j'utilise un fichier REG pour "pousser le réglage du WSUS et utilise bien l'IP du serveur 2003R2 sur le port 80.
- les deux serveurs se "voient" l'un l'autre sans souci (ping possible dans les deux sens).
- depuis le 2012R2, avec un navigateur, j'arive bien sur la page par défaut du serveur 2003R2 (le serveur WSUS), donc IIS fonctionne bien.
- d'autres postes et serveurs fonctionnent très bien.
- cette machine n'arrive même pas dans la base du WSUS.
- erreur reportée : 800B0001 (soit disant une erreur de communication).

La je sèche ...

Edit > Utilisé l'outil : erreur 0x00070002, je fouille avec ça.

Edit bis > Suivi ceci : (pas d'erreur à l'application), sans résultat : https://support.microsoft.com/fr-fr/kb/910336
Retour à la case départ ...

Edit ter > Avec le message complet ça sera mieux je pense :

Il suffit pas du SP2, tu as d'autres mises à jour à installer sur l'ensemble des WSUS pour bien supporter les derniers produits et OS (mais à priori tu as bien la main dessus).
 
Pourquoi passer par du registre quand tu peux configurer ça via GPO ? Les deux serveurs n'ont pas été clonés ?

Non, pas de clones et le WSUS actuel (qui s'avère assez malade au passage) est en workgroup. J'aurai plus vite fait d'en refaire un propre en 2012R2, j'ai des licences de RAB', donc pas de soucis à ce niveau.

Sinon, et signe que le 2003 est malade, j'ai du rebooter ce dernier pour que mon 2012R2 puisse le joindre.

Maintenant, les recherches de màj passent et les installations aussi.

Edit > Je suis obligé de le laisser en autonome car il doit écouter sur deux LAN différents et je ne veux pas de soucis de duplication DNS (attaque par l'IP de toutes manières).

AH mais si tu pars sur des config moisies du type workgroup + double IP, tu vas forcément avoir des problèmes aussi

C'est la VM 2003 qui a un gros malaise en fait. Et c'est même pas du 2003 R2 ... Le souci que j'ai eu est que la couche TCP s'était à moitié vautré la gueule. A coté, sur le même système, des VM 2003R2 sont autrement plus stables.

Pour la double IP, c'est normal car j'ai deux LAN différents qui doivent y accéder, ceci sans passer par le WAN (but du jeu). Et, pour ne pas avoir de soucis de DNS, surtout pas de domaine.

Je ferais bien mieux d'en remonter un propre en 2012R2 tout propre sur le même principe (et toujours en autonome pour ne pas me mayer els soucis de duplication DNS). Pour info, l'infra de virtualisation est du Vsphere (qui marche très bien) avec deux hyperviseurs.

Bon, VM 2012 R2 mise en place avec les rôles WSUS et IIS (obligatoire). Le WSUS est bien réplica d'un serveur national (pas direct Microsoft) et reçoit bien les mises à jour. IIS répond bien, testé depuis une machine cliente.

Seul souci : mes machines clientes ne veulent pas "SUSer" (comprendre : s'inscrire sur le serveur WSUS), bien que tout semble fonctionner coté serveur et que j'ai bien appliqué un REG pour forcer l'addresse IP du serveur pour le WSUS.

Erreur rencontrée à la recherche de mises à jour : 80244019. Et chose intéressante, le WindowsUpdate veut toujours chercher les mises à jour directement chez Microsoft (proxifié). Une idée ?

Ce qui m'embête, c'est que, même si la machine ne trouve pas de nouvelle mise à jour, elle devrait pouvoir toucher le serveur et s'inscrire dessus (serveur hors domaine car sur deux "pattes" réseau). Accès par IP et pas nom de machine.

Il faut que tu ai configuré ton WSUS pour utiliser une conf via GPO, et que tu pousses bien toutes les clés de registre nécessaire avec les bonnes valeurs. Enfin il faut que le client Windows Update des postes soit assez récent pour communiquer avec le serveur et se mettre à jour par la suite.
ENfin ça, c'est dans le cas d'une infra propre, ce qui n'est pas ton cas

Pour le GPO, je peux le pousser, mais les tests montrent que le souci doit se poser coté serveur WSUS (neuf !) car mes machines clientes ne parviennent pas à s'inscrire. J'ai carrément désactivé les parefeu sur le serveur pour être sûr, même chose. J'ai du 404 et recherche chez MS (interdit). Mon REG est bien appliqué sur les postes.
 
Le REG en question :

(IPs modifiées dans la citation)

Et un extrait du WindowsUpdate.log :

Tu mets des clés de registre à la fois computer et user, ça sert à rien enlève les secondes.
Je pourrais vérifier si les autres sont OK à l'occasion.
 
ENcore une fois vérifie la façon dont ton WSUS identifie les machines avant tout. Rien dans Unassigned computers ?

Que dalle. Aucune machine ne parvient à s'inscrire sur le serveur WSUS. J'en conclus donc que le souci provient bien du serveur, pas des clients. Ce qui est bizarre, c'est que IIS répond parfaitement bien (page par défaut du moins) sur les deux IP de la machine (deux LAN différents). Ce serveur étant un réplica d'un serveur national, je n'ai pas de complète maitrise dessus. Le serveur national s'accède par le port 80, si cela a une incidence.

Je supprime les clefs USER et retente.

Edit > KO. Le souci est vraimetn coté serveur . Et je suis obligé d'utiliser une telle configuration car je ne veux surtout pas de flux WAN (économie de bande passante) pour les mises à jour Windows.

Rappel :
- deux directions départementales (dans le même bâtiment)
- deux LAN différent (un par direction) avec un accès WAN par direction (deux routeurs différents)
- une seule baie de virtualisation qui a des "pattes" sur les deux LAN
- un seul domaine AD pour les deux entités (un serveur AD/DNS par LAN et réplication OK par le WAN - peu de trafic)

Auparavant, avant crash de l'ancien serveur WSUS 2003 non R2, cela fonctionnait bien. Maintenant, impossible de faire entendre raison au nouveau serveur.

ENFIN ! Ce foutu serveur WSUS daigne marcher et accepter mes postes (happy).
 
Donc, il faut bien spécifier le port dans l'URL car sinon les clients ne parivennent pas à toucher le serveur ni à s'inscrire.

C'est d'ailleurs spécifié dans la doc Technet de mémoire