Architecture / Microsoft / Network / Security
en voulant configurer un Windows Server 2008 R2 afin de télécharger les mises à jour, j’ai eu droit au message d’erreur suivant:
cscript c:\windows\system32\scregedit.wsf /AU 4
Scregedit.wsf(777, 3) (null): 0x80240037
un procmon plus tard, j’ai supprimé la clé suivante (pour le moins « étrange », le serveur étant en workgroup):
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
Et voilà !
Voici quelques commandes que j’ai utilisé cette semaine…Puisque cela m’a aidé, peut être que cela vous aidera aussi !
Besoin: connaître les utilisateurs qui n’utilisent pas le mode mise en cache de outlook.
Solution: Exchange 2007 possède un cmdlet PowerShell qui correspond tout à fait:
Get-LogonStatistics -server MonServeurExchange | where {$_.ClientMode -eq "Classic"} |FL ClientName
Besoin: Collecter les adresses IP assignées aux serveurs.
Solution:
Le « script » powershell est le suivant:
———————————————————————————————-
get-content servers.txt | foreach-object {
$server=$_
$ip=.\psexec \\$server ipconfig /all| where { $_ -match "IP Address"} | %{$_ -replace "IP Address. . . . . . . . . . . . : ","$server;"}
Write-Output $ip >> servers_ipconfig.txt
}
for /f %s in (servers.txt) do echo %s >>ipall.txt && psexec \\%s ipconfig /all | findstr "Address" | findstr "IP" >> ipall.txt
J’ai été récemment confronté par deux fois à d’importantes lenteurs sous SharePoint 2007:
IIS essaye de contacter crl.microsoft.com en http, mais n’y arrive pas. Ceci afin de vérifier la signature des assembly dans le GAC .Net. Les symptômes ainsi que des solutions sont proposées sur ce blog:
http://www.muhimbi.com/blog/2009/04/new-approach-to-solve-sharepoints.html
J’ai choisi la méthode suivante:
Et voilà, on passe à environ 20 secondes, ce qui est « normal » dans la mesure où il doit compiler. Vous pouvez aller encore plus loin en:
Symptômes: vous essayez d’autoriser un utilisateur, un groupe, ou juste assigner une tâche à quelqu’un, cela prends au moins 30 secondes au lieu d’une seconde en général. Je parle ici du temps entre le moment où l’on clique sur la recherche et le moment où le nom est souligné (donc validé).
Analyse du problème: dans mon cas, en traçant l’activité réseau du serveur, on se rend compte qu’il essaye de contacter en vain des contrôleurs de domaines d’une autre forêt en vain au même moment à plusieurs reprise. Cette tentative de connexion est dûe à l’ajout d’une autre forêt via stsadm pour la propriété peoplepicker. Par défaut, SharePoint ne cherche des utilisateurs que dans le domaine où il est. Pour étendre la recherche à d’autre domaines/forêt, il faut les ajouter avec cette commande:
stsadm -o setproperty -url http://SharePointSite:85 -pn peoplepicker-searchadforests –pv “domain1.com”,<loginname1>,<password1>;”domain2.com”,<loginname2>,<password2>
S’il y a une relation d’approbation entre les forêts, il n’y a pas besoin de spécifier un login et un mot de passe.
Voici un post plus détaillé sur le sujet: http://www.gk.id.au/2009/04/people-picker-sharepoint-and-forest.html
Solution: Autoriser les serveurs SharePoint à se connecter aux contrôleurs de domaines de la forêt ciblée. Le port à ouvrir est ldap (389) à la fois en TCP et UDP.
Et voilà, la recherche prend de nouveau environ une seconde et on peut maintenant aussi chercher des utilisateurs de l’autre forêt!
Comme de plus en plus de produits Microsoft (et autres éditeurs), les solutions tendent à être de plus en plus complexe. Il a beau faire partie de la gamme « System Center » de Microsoft, il quelques singularités auxquelles je me suis frotté récemment. Installé avant mon arrivé, on a souhaité déplacer les bases de données associées au produit d’un serveur SQL à un autre.
1er challenge: où est stocké le nom du serveur SQL ?
Recherche dans la base de registre (comme SCOM) ? rien
Recherche dans les fichiers dans le répertoire d’installation ? rien
Il stocke l’information dans Active Directory (un SCP / Service Connection Point). Un petit coup d’adsiedit plus tard, il pointe sur le nouveau serveur SQL
Ce point est évoqué dans un article Technet lors de la restauration des bases
2ème challenge: SQL
L’équipe du produit utilise pleinement SQL Server, notamment:
Cela me semble assez « riche » pour ce type de solutions, mais bon… Vous l’avez compris, il faut sauvegarder et restaurer la clé d’encryption de l’instance de l’ancien serveur SQL…
Pour rappel, les bases SQL pour MDM portent les noms suivants:
La documentation Microsoft du produit: http://technet.microsoft.com/en-us/scmdm/cc304592.aspx
Je n’avais pas utilisé bginfo de sysinternals depuis quelques temps. Comme d’hab, je mets un fond avec notamment le logo de l’entreprise, et là surprise au moment de l’enregistrement:
(Error saving settings to registry: The operation completed sucessfully)
Pour les non anglophones, il y a donc une erreur à l’enregistrement dans la base de registre, mais l’opération à réussi…Surprenant hein ?
Evidemment, grosse déception, point de fichier bgi…
Contexte:
Que faire quand un outil sysinternal échoue ? Utiliser un autre outil Sysinternal pour diagnostiquer !
Process monitor montre notamment une erreur pour « ressource insuffisante« :
Process explorer montre que le système est utilisé et manque un peu de ressource (quoi que, encore 742Mo de ram disponible tout de suite)
J’essaye sur ma station avec 8Go de ram, idem…Windows XP: idem!
Finalement, j’ai réduit et importé de nouveau l’image, fonctionne nickel.
Je me suis permis un petit mail à Mark Russinovich…Retour une heure plus tard:
« Thanks for the bug report, Mathieu. It looks like Bginfo was trying to write 7MB to the registry.«
on m’a demandé de remettre sur pied une plateforme SCOM 2007, en commençant par une réinstallation. J’ai donc désinstallé SCOM du serveur, et supprimé les bases de données du serveur SQL distants.
Après l’installation, SQL indiquait que le service broker était déjà activé…Bonne surprise ou annonce d’autres problèmes ? J’ai eu droit à la deuxième hypothèse…
Suite à la réinstallation, j’ai eu quelques problèmes liés à SQL (An exception occured while enqueuing a message in the target queue):
Résolution:
declare @conversation uniqueidentifier
while exists (select 1 from sys.transmission_queue)
begin
set @conversation = (select top 1 conversation_handle from sys.transmission_queue)
end conversation @conversation with cleanup
end
Et voilà, le discovery fonctionne de nouveau aussi, car il dépend des messages passant via le broker.
La technologie NLB (Network Load Balacing) de Microsoft a l’avantage d’être intégrée directement avec le système d’exploitation. Comme son nom l’indique, est permet de répartir la charge sur plusieurs noeuds, qui sont membre de la ferme (cluster). La mise en route est très simple en apparence, mais il y a cependant plusieurs points à ne pas négliger, sous peine d’avoir l’impression que tout va bien sans que ca soit le cas…
Impact sur le réseau
NLB peut fonctionner dans deux modes:
Lequel choisir ? Ca dépend! Les variables à prendre en compte pour faire son choix:
Supervision et disponibilité
Il est vrai que si un noeud disparait du réseau, les autres prennent la relève. Mais on entend par là une coupure franche. Si vous avez 2 serveurs dans la ferme, et que vous arrêtez votre application métier sur un noeud, il continuera à recevoir autant de requête que l’autre, et il y aura donc la moitié des utilisateurs « dans le vent ». NLB travaille au niveau 3 (IP), et n’a pas conscience de ce qui ce passe plus haut, au niveau applicatif. Même si le port TCP n’est plus écouté, il n’en aura pas conscience. C’est le grand point faible de NLB. Microsoft incluait sentinel dans le resource kit. Il permettait de tester une page web sur chaque noeud et de le sortir de la ferme en cas de problème. ISA 2006 gère le NLB est peut sortir de la ferme en cas de problème dans ISA. Pour le reste, c’est à vous de combler le manque. S’il s’agit d’un site Web sous IIS, vous pouvez modifierLoadBalancerCapabilities dans la metabase de IIS afin de remplacer un 503 par un reset TCP. Le client va ainsi recommencer la requête et aller sur un autre serveur.
Pour combler le manque, vous pouvez utiliser votre solution de supervision (ou un script en boucle sur chaque nœud). L’idée est de tester chaque noeud d’un point de vue applicatif, et de le sortir de la ferme en cas d’erreur. Cela implique plusieurs éléments à étudier:
La solution SCOM prends alors de l’intérêt, notamment via l’implémentation de trigger sur évènement (eventlog, fichier de log…)
NLB versus MSCS ?
Un cluster MSCS est prévu pour être actif/passif. A un instant T, les ressources sont sur un seul serveur, qui doit donc pouvoir supporter toute la charge. Il a l’avantage de pouvoir gérer des données partagées (espaces disques), et de pouvoir superviser des ressources (état de services Windows). Là aussi, cela ne couvre pas l’application dont le service Windows est bien démarré, mais qui ne fonctionne plus (perte de l’accès à la base de données..).
Autre solution ?
KB/Articles:
IIS Responses to Load-Balanced Application Pool Behaviors
NLB Operations Affect All Network Adapters on the Server
Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003
The « NLB troubleshooting overview for Windows Server 2003 » article is available
An update enables multicast operations for ISA Server integrated NLB
Terminal Services Client Cannot Connect to NLB Cluster TCP/IP Address
The NLB WMI Provider Generates a Lot of Error Entries in the Wbemcore.log File
Je suis déjà inscrit 🙂
Le 64 bit fut longtemps « réservé » si je puis dire aux systèmes ayant des besoins très importants (calculs ou allocation mémoire), au départ sur Unix (True64…). Il s’est peu à peu démocratisé, jusqu’à avoir les OS postes clients Microsoft eux aussi en 64 bit. Cependant, l’intérêt du 64 bit ne parait pas évident de prime abord, on l’évoque seulement comme passage obligé pour profiter pleinenement d’un système avec plus de 4Go de mémoire. Microsoft a « jeté un pavé dans la mare » en supportant Exchange 2007 uniquement en 64 bit en production. La deuxième couche arrive avec Windows 2008 R2, qui sera seulement supporté en 64 bit en production.
Pourquoi freiner le passage au 64 bit en entreprise ?
Apple, avec Snow Leopard, a finalement fait le choix de la rupture: Ils ne fournissent qu’une version 64 bit. Les iMac et autre anciens mac n’auront donc pas droit à la mise à jour. Les éditeurs vont être forcés de sortir des versions 64 bit décentes.
Faut-il donc être le maillot jaune du 64 bit ? Je ne pense pas, à moins d’avoir des besoins avérés réels. Cependant, déployer du 64 bit en 2009 ne fait plus de vous un maillot jaune ! Il ne faut cependant pas négliger la gestion du changement auprès de vos équipes systèmes et surtout développements. Je recommande, comme toujours, de penser grand mais commencer petit. Profitez de nouveaux projets pour vous faire la main (enfin le plutôt le cerveau!). Cela évite aussi de refaire une recette juste pour le passage au 64 bit.
Voici une proposition d’ordre déploiement:
Ayant commencé l’informatique sur Linux/FreeBSD, j’ai mes petites habitudes pour analyser des logs (awk/sed/cat/sort/uniq…).
Récemment cygwin, un port de shell Unix (bash) et outils diverses s’est mis à ne plus fonctionner:
Il s’agit donc d’un problème sur cygwin1.dll. Effectivement, j’utilise aussi en ce moment un autre outil, John the ripper, qui a été porté sur Windows via cygwin.
La DLL pour JTR est beaucoup plus ancienne que mon installation de cygwin. Démarrer dans l’ordre inverse donne le même résultat, c’est JTR qui plante.
Procmon de Sysinternals indique bien que chaque programme charge la dll cygwin1.dll de son répertoire, mais JTR lis la DLL et fini par « Load image » alors que cygwin fait uniquement un « Load image »:
Process Explorer m’a permis de mettre en évidence d’où vient le problème. Cygwin1.dll utilise un handle de type section qui porte le même nom quelque soit la version de la DLL.
Voici les handles pour JTR:
Voici les handles pour cygwin lui même (bash.exe)
J’ai pu confirmer le diagnostique en utilisant une fonctionnalité de Process Explorer: fermer arbitrairement un handle:
Le shell Cygwin (bash.exe) se lance maintenant, alors que JTR tourne toujours. Je ne sais pas cependant si cela peut avoir des conséquences dans JTR:
