My Memory Dump

Aller au contenu | Aller au menu | Aller à la recherche

mardi 14 juillet 2015

Echec d'envoie des abonnements SSRS

Symptôme : Certains utilisateurs s'abonnent à un rapport SSRS, ils choisissent le mode d'envoi par mail, ils définissent une planification et ils cochent la case "Inclure un rapport" pour recevoir le rapport dans le corps du mail (au format html ou autre). Lorsque l'heure d'exécution arrive, certains utilisateurs ne reçoivent pas le mail. Au niveau de l'abonnement, la colonne état indique :

Échec de l'envoi du message électronique : Le serveur de rapports a rencontré une erreur de configuration. Le message ne sera pas renvoyé.

Si on vérifie les logs dans "C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\LogFiles" l'erreur suivante apparait au moment de l'exécution de l'abonnement :

AuthzInitializeContextFromSid: Win32 error: 1355

Diagnostique : Lors de la génération du rapport à inclure dans le mail, SSRS doit vérifier que le propriétaire de l'abonnement a bien le droit de consulter le rapport. Pour cela, l'authentification Kerberos est utilisée. En faisant des captures de trame dans le cas ou cela échoue, la requête TGS-REQ reçoit la réponse KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. Dans le cas ou l'abonnement fonctionne, on voit que le serveur contacte le contrôleur de domaine de l'utilisateur propriétaire de l'abonnement. Voilà pourquoi cela fonctionne pour certains et pas pour d'autres. Les utilisateurs pour lesquels l'abonnement fonctionnent font parti du même domaine que le serveur. Pour les autres, et bien le serveur n'est pas en mesure de communiquer avec les contrôleurs de domaine.

Solution : La solution logique consiste à permettre la communication entre le serveur SSRS et les contrôleurs de domaine des domaines des utilisateurs et peut-être de définir un SPN (service principal name) vu le message d'erreur dans la capture de trame. Mais je n'ai pas testé cette solution.
Le serveur SSRS était externalisé et la communication avec le contrôleur de domaine de son domaine établie via un VPN qu'on ne souhaitait pas faire évoluer. Dés lors la solution a été de mettre à jour le propriétaire des abonnements avec un compte appartenant au domaine avec lequel le serveur était capable de communiquer. Pour cela il suffit de faire un update dans la table "Subscriptions" en remplaçant le "OwnerID". "OwnerID" que l'on trouve dans la table "Users". Planifier cet update une fois par jour via un script et une tâche planifiée.

samedi 2 mai 2015

Windows 8.1 - IE11- proxy auto détection

L'utilisation de l'auto détection de proxy sur les stations de travail est discutable (voir cet article). Quoiqu'il en soit nous l'utilisons. Après avoir migré de Windows 7 + IE9 à Windows 8.1 + IE11, le problème suivant est apparu.

Symptôme : Au premier lancement d'internet explorer 11, la page de démarrage (notre intranet) mettait 10 à 15s pour s'afficher. Pendant ce temps le navigateur affichait une page blanche et semblait inactif. Ce problème ne se produisait plus lors des lancements suivants mais pouvait réapparaitre dans la journée.

Rappel : L'auto discover du proxy fonctionne en recherchant l'enregistrement DNS wpad.mondomaine.com puis le navigateur accède à la page http://wpad.mondomaine.com/wpad.dat. Le fichier wpad.dat contient au minimum le nom du proxy mais il peut aussi être personnalisé pour traiter des exceptions, par exemple ne pas utiliser le proxy pour les adresses internes.

Cause n°1 : En faisant une capture de trames réseau sur une station de travail avec wireshark, j'ai constaté que la machine effectue des diffusions via le protocol LLMNR (Link-Local Multicast Name Resolution). Il s'agit d'un mode de résolution de nom par diffusion qui n'est utile qu'en absence de serveur DNS. Non seulement ces diffusions sont inutiles mais elles prennent du temps.

Cause n°2 : Après avoir désactivé le protocole LLMNR, la capture de trames montre des diffusions NETBIOS. Ces diffusions sont également inutiles.

Solution : Désactiver LLMNR et NETBIOS sur les stations de travail. Pour cela, créer une GPO ordinateur pour effectuer les actions suivantes :
- Créer la clé de registre suivante pour désactiver LLMNR :
REG ADD "HKLM\Software\policies\Microsoft\Windows NT\DNSClient\" /f
REG ADD "HKLM\Software\policies\Microsoft\Windows NT\DNSClient" /v "EnableMulticast" /t REG_DWORD /d "0" /f

- Exécuter le script de Mark Harris au démarrage pour désactiver NETBIOS over TCP/IP

' Disable NetBIOS over TCPIP
' Author: Mark Harris
' disablenetbios.vbs
' run as cscript /nologo disablenetbios.vbs

strComputer = "."
' set to HKEY_LOCAL_MACHINE registry Hive
HKLM = 2147483650

' Set keyword value to open
valuename = "NetBIOSOptions"
subkey = "System\CurrentControlSet\Services\NetBT\Parameters\Interfaces\"

'Get registry provider from WMI
set registry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

'Get subkeys of Interfaces key … these will be random GUIDs
registry.EnumKey HKLM, subkey, subkeys

for i = 0 to ubound(subkeys)
'Set hex value of registry value to 0x2. We have to use the built-in VBscript hex function to convert from decimal to hex data type
registry.SetDWORDValue HKLM, subkey & subkeys(i), valuename, hex(2)
next

vendredi 3 avril 2015

PXE-E53: No Boot filename received

Symptôme : Erreur reçue par un modèle de machines sur le réseau lors d'un démarrage en mode PXE pour déploiement d'image WDS. Aucun problème sur les autres modèles.

PXE-E53: No Boot filename received
PXE-M0F: Exiting intel PXE rom

Cette erreur indique que le client PXE n'a pas reçu de réponse du serveur WDS concernant le nom du fichier de boot a télécharger/exécuter.

Contexte : Serveur DHCP Windows 2008 R2 et Serveur WDS 2012 R2. Serveurs distincts donc pas besoin de configurer d'options DHCP particulières. Toutes les machines sont dans le même VLAN.

Cette erreur est bien référencée par Google avec différents points à vérifier (voir les liens plus bas) mais dans mon cas cela ne m'a pas aidé. J'ai fait deux captures de trames réseau avec Wireshark, l'une en cas de succès et l'autre en cas d'échec (filtrer sur le protocole "bootp"). Captures effectuées sur le serveur WDS lui-même. Dans les deux cas la communication avec le serveur DHCP se passe bien :
- Client : DHCP Discover
- Serveur : DHCP offer
- Client : DHCP request
- Serveur : DHCP Ack
puis le serveur WDS prend la suite :
- Serveur WDS : DHCP offer
- Client : DHCP request
- Serveur WDS : DHCP ack
Le client peut alors télécharger le fichier de boot.

Dans le cas d'échec, je constate que le serveur WDS ne répond pas au DHCP request envoyé par le client.

Solution de contournement 1 : Après avoir fait différents tests, je constate que ce problème ne se produit que si la version de l'intel boot agent présent sur le poste client est en version 1.5.x ou supérieur. Si je downgrade le BIOS de la machine (BIOS et boot agent marchent ensembles), je repasse le boot agent en version 1.4.x et je n'ai plus de problème.

Solution de contournement 2 : Si je reconfigure mon serveur WDS en choisissant le mode "Standalone" au lieu de "intégré à active directory" au début de l'assistant de configuration, le problème disparait.

WDS

Solution définitive : L'ouverture d'un ticket au support Microsoft a abouti à la solution de contournement 2, ne pas utiliser le mode "intégré à active directory". Microsoft considère que le problème vient de l'agent de boot PXE et que c'est aux constructeurs de se rendre compatible.

Liens utiles :
http://www.symantec.com/business/support/index?page=content&id=TECH10532
http://blogs.technet.com/b/configurationmgr/archive/2011/01/05/troubleshooting-the-pxe-service-point-and-wds-in-configuration-manager-2007.aspx