Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
   1. Mars 2017
      1. KB4012598
2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
   1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
   2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
   3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
3. Pour Windows Server 2012 :
   1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
   2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
   3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
4. Pour Windows 8.1 et Windows 2012 R2 :
   1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
   2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
   3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
5. Pour Windows 10 (Release 1511) :
   1. Mars 2017
      1. KB4013198
      2. KB4016636
   2. Avril 2017
      1. KB4015219
   3. Mai 2017
      1. KB4019473
6. Pour Windows 10 (Release 1607) :
   1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
   2. Avril 2017
      
      1. KB4015217
   3. Mai 2017
      
      1. KB4019472
      2. KB4023680
7. Pour Windows 10 LTSB : 
   1. Mars 2017 
      1. KB4012606
      2. KB4016637
   2. Avril 2017
      
      1. KB4015221
   3. Mai 2017
      
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

Lors de l’installation manuelle d’un agent SCOM (sans passer par l’assistant de la console SCOM), celui-ci doit, par défaut, être approuvé manuellement en passant par les Pending Management de l’onglet Administration de la console.

Dans de rares cas, il peut arriver que malgré une configuration correcte l’agent à approuver (ici nommé « 002 ») n’apparaisse pas et remonte les tant redoutées erreurs 21106 et 20070 indiquant que l’agent n’est pas autorisé à communiquer avec son serveur :

Par contre, l’agent apparait bien lorsqu’on utilise powershell :

Get-SCOMPendingManagement |where {$_.agentname –like ‘xxx’}

Il est alors possible de l’approuver également via Powershell :

Get-SCOMPendingManagement |where {$_.agentname -like ‘xxx’} | Approve-SCOMPendingManagement

Et le tour est joué, l’agent parvient maintenant à communiquer :

Une astuce bien utile, même si elle ne devrait pas vous servir tous les jours!

Bonjour à tous,

Qui n'a jamais rencontré d'échecs lors de la mise en domaine d'un poste ?

Les messages d'erreurs fournis à cette occasion ne sont pas forcément des plus explicites, ni des plus détaillés.

Heureusement il y a une solution et celle-ci s'appelle NetSetup.log

Vous trouverez ce fichier dans le dossier C:\Windows\debug.

Pour ce qui est de la structure du fichier, vous pouvez vous référer à la capture ci-dessous, mais voici un résumé des informations contenues dans celui-ci :

• Nom du contrôleur de domaine contacté pour la jonction au domaine
• Nom du site Active Directory détecté
• Identifiants utilisés pour la jonction
• OU de destination du poste
• Résultats lors de la création de l'objet ordinateur (SPNs, Nom DNS, ... )
• Etc ...

Bonne découverte !