Actualités Windows NT / 2000 – Semaine 44 – 2004

Toutes les Actualités du 25 au 31 Octobre 2004

News iSeries – Semaine 42 – 2004

Toutes les actualités du 11 au 17 Octobre 2004

Trop, c’est combien ?

par Jeffrey Bane - Mis en ligne le 29/09/2004 - Publié en Octobre 2003

En conception de base de données, la bonne relation est primordiale

Si le rôle de l'administrateur et du développeur de bases de données modernes se limitait à  coder SQL et à  assurer de bonnes sauvegardes, nous dormirions tous probablement mieux et pourrions consacrer davantage de temps à  nos loisirs. Malheureusement, nous devons aussi avant tout mettre en oeuvre des bases de données efficaces...Cette tâche est l'une des plus délicates dans le monde des bases de données, car la conception et la mise en oeuvre d'une base de données est un exercice lourd de conséquences positives ou négatives.
Le temps et l'expérience aidant, on atteint une certaine aisance malgré l'ampleur de la tâche. Et vous atteignez un point dans votre courbe d'apprentissage de développement de base de données où vous maîtrisez bien l'application des relations many-to-many (M:N) (de plusieurs à  plusieurs) entre les tables. Parfois même, vous vous sentez tellement à  l'aise que vous avez tendance à  abuser de ces relations.
Si vous êtes un développeur de bases de données débutant, la relation M:N risque de vous intimider. Mais, après plusieurs utilisations, vous constaterez qu'elle est relativement simple à  identifier, concevoir et mettre en oeuvre. En général, parvenue à  ce point de maîtrise, la courbe d'apprentissage se heurte à  un mur. Très peu de développeurs et de concepteurs de bases de données se risquent au-delà  des relations « Big 3 » : one to one (1:1), one to many (1:M) et M:N, pour découvrir les autres types de relations pouvant exister dans un schéma relationnel. Peu de gens explorent, mais moins encore maîtrisent, des types de relations plus obscures du genre tertiaire ou nomenclature. Pourtant, ces relations ne sont que de simples extensions des trois types de relations avec lesquelles vous vous sentez à  l'aise. Par exemple, une relation nomenclature n'est rien d'autre qu'une entité qui a des relations M:N avec elle-même. Dans cette relation, une entité pièces est constituée d'autres pièces qui, à  leur tour, sont constituées de - vous l'aviez deviné - encore d'autres pièces. Mais, si l'on comprend les relations M:N, on est tout près de comprendre la relation nomenclature.
Ces types de relations moins usuelles ne doivent pas constituer un mystère dans vos schémas de bases de données. Pour démystifier ces relations, voyons la relation supertype- subtype sous-utilisée et souvent incorrectement mise en oeuvre. Elle est aussi connue sous le nom de relation superclass-subclass. Si vous avez déjà  pratiqué le développement orienté objet, vous connaissez cette relation, dans laquelle plusieurs entités partapartagent certains attributs, mais pas tous.
A noter que dans cet article, je couvre principalement la mise en oeuvre physique d'une relation supertype- subtype, en expliquant la logique de ce type de relation et en soulignant les gains de performances spectaculaires qu'elle permet. Pour une explication approfondie des relations supertype- subtype au niveau logique, voir l'article classique de Michel Poolet « Supertypes and Subtypes », mai 1999, sur www.itpro.fr.

PowerToys de Windows XP

par Ed Roth - Mis en ligne le 20/10/2004 - Publié en Février 2004

Enrichissez XP avec ces add-ons utiles

Chaque release de l'OS client Windows a été flanquée d'un ensemble d'utilitaires add-on appelés PowerToys, et Windows XP continue dans cette voie...PowerToys améliore de diverses manières l'OS de base. Microsoft PowerToys for Windows XP est un ensemble de 10 téléchargements séparés que l'on peut obtenir à  cette adresse

News iSeries – Semaine 38 – 2004

Toutes les actualités du 13 au 20 Septembre 2004

Les nouveautés de la semaine 2 – Windows IT Pro – 2005

Tous les nouveaux produits du 10 au 16 Janvier 2005

Les JSP : Visite rapide

par Greg Hintermeister - Mis en ligne le 1/12/2004 - Publié en Février 2004

Les développeurs Net.Data adopteront probablement les JSP dans la foulée

Beaucoup d'entre vous construisent déjà  des applications Web en utilisant Net.Data. Le principe est le suivant : un développeur fournit des pages Web personnalisées qui fusionnent HTML avec SQL et les propres commandes script de Net.Data pour les parties dynamiques. A l'exécution, le moteur Net.Data exécute le script et les éléments SQL, en les remplaçant par des données et en délivrant en fin de course une page Web normale à  l'utilisateur demandeur ...Si vous maîtrisez déjà  Net.Data, vous n'aurez probablement pas de mal à  utiliser les JSP (Java Server Pages). Les JSP sont une technologie Java côté serveur complémentaire des servlets (les programmes Java qui produisent des pages Web). Le développeur commence par une page Web et ajoute Java pour scripter les parties dynamiques. Après quoi, un moteur runtime traduit cela en une page Web normale.
Je présente ici un exemple simple mais néanmoins intéressant d'un JSP à  l'oeuvre. On ne prend en compte que deux fichiers :

selection.html - une page Web où vous choisissez des critères de sélection pour filtrer les résultats d'interrogation d'une table

tableDisplay.jsp - le JSP qui affiche les lignes provenant de la table interrogée

LTC 1000 et XTC 1000 pour iSeries

BOSaNOVA présente les thin clientsLTC 1000 et XTC 1000 pour iSeries et autres plates-formes.

Destinés à fonctionner avec OpenOffice et d'autres solutions basées Java qui marchent respectivement sous Linux et Windows XP Embedded, les deux clients offrent notamment une connectivité ICA Citrix et 10/100 Ethernet, un standard PCMCIA.

Sécuriser le traffic SMTP Email

par Paul Robichaux - Mis en ligne le 22/12/2004 - Publié en Novembre 2003

TLS (Transport Layer Security) vous amène vers les 100 % de sécurité du e-mail

Comme le standard SMTP envoie le e-mail sans cryptage ni authentification, chaque message envoyé est exposé à  la vue. Des solutions côté client comme Secure MIME (S/MIME) ou PGP (pretty good privacy) peuvent résoudre ce problème, mais à  condition que vous interveniez en tant qu'utilisateur. Il vaut mieux concentrer vos efforts sur la sécurisation du trafic SMTP ...En effet, si vous pouvez sécuriser SMTP, vous serez tout près de 100 % de sécurité pour le trafic mail que l'un de vos serveurs envoie ou reçoit.
Microsoft Exchange Server offre plusieurs outils pour sécuriser le trafic e-mail. Pour sécuriser SMTP, l'une des méthodes consiste à  utiliser SSL (Secure Sockets Layer) pour les connexions SMTP. Toutefois, cette méthode soulève un problème. Par défaut, tous les serveurs SMTP utilisent le port 25. Mais, si vous utilisez SSL sur le port 25, les serveurs non SSL ne pourront pas se connecter par l'intermédiaire de ce port. Et, si vous utilisez un numéro de port non standard, les autres serveurs ne pourront pas trouver vos serveurs.
Vous pouvez contourner cette difficulté. Le verbe STARTTLS (qui fait partie du jeu de commandes ESMTP - Extended SMTP) permet à  un client et à  un serveur SMTP de négocier l'utilisation de TLS (Transport Layer Secure) pour une connexion SMTP. Chaque bout de la connexion peut choisir d'authentifier l'autre, ou bien la connexion TLS peut être utilisée uniquement dans un but de confidentialité. Dans tous les cas, cette méthode offre trois avantages importants :

• Elle n'interfère pas avec les autres serveurs et clients. Les clients qui supportent STARTTLS peuvent l'utiliser ; les autres peuvent continuer à  utiliser SMTP non crypté.
• Elle est opportuniste. Quand vous validez l'utilisation de TLS avec SMTP, votre serveur demande automatiquement TLS quand il communique avec d'autres serveurs et il accepte les connexions TLS quand elles lui sont demandées. En supposant que l'autre serveur boucle le processus de négociation, le flux de courrier électronique est protégé. (Toutefois, il vous faudra le plus souvent demander à  vos utilisateurs de valider SSL/TLS dans leurs clients mail Internet.)
• Le cryptage en TLS du flux SMTP protège également les en-têtes de messages, procurant un degré de protection supplémentaire contre les analyses de trafic permettant à  des intrus dans le réseau de savoir avec qui vous communiquez et avec quelle fréquence./

SQL Server Actualités – Semaine 46 – 2004

Les actualités SQL Server pour le mois de Novembre 2004

Les nouveautés de la semaine 44 – Windows 2000 et .Net – 2004

Tous les nouveaux produits du 25 au 31 Octobre 2004

News Exchange : Semaine 42 – 2004

Toutes les actualités d'Octobre 2004 pour Exchange Server

DTS itinérant

par Shane Dovers - Mis en ligne le 16/09/2004 - Publié en Octobre 2003

7 conseils pour une portabilité de package maximale

Lorsqu'on crée un package DTS, il est très important de le doter d'un maximum de portabilité. C'est ce que m'ont appris les 5 années de programmation DTS (Data Transformation Services) effectuées depuis la première livraison de SQL Server 7.0. La portabilité est maximale quand un package peut s'exécuter correctement sur la grande majorité des serveurs...Lorsque la portabilité est présente dans la conception du package, on peut déplacer le package d'un serveur sur un autre, avec peu ou pas de modifications. Cette notion est importante parce que la plupart des développeurs créent les nouveaux packages sur des serveurs de développement, puis transportent la version testée finale sur un serveur de production. Si l'on n'effectue pas toutes les modifications liées au serveur avant de porter le package sur le serveur de production, le package DTS ne s'exécutera pas correctement. Les conseils qui suivent vous aideront à  réduire le nombre de modifications nécessaires lors du déplacement d'un package et à  réduire votre temps de mise au point.
Examinons sept manières d'obtenir un maximum de portabilité quand on programme des packages DTS. Nous nous intéresserons aux deux aspects de portabilité les plus négligés : localisation des composants et sécurité à  l'exécution. Ensuite, nous étudierons les variables globales avec la Dynamic Property Task pour valider les changements dynamiques à  l'exécution, les inconvénients liés à  l'utilisation de Send Mail Task, l'utilisation des chemins UNC (Universal Naming Convention), le stockage des, et l'accès aux, fichiers source et de destination et, finalement, l'utilisation de Disconnected Edit pour modifier les attributs du package DTS.

Prévoir le basculement des DC

par Sean Deuby - Mis en ligne le 13/10/2004 - Publié en Février 2004

Comment créer la meilleure topologie de site AD possible

La plupart des administrateurs savent qu'une bonne topologie de site AD (Active Directory) Windows 2000 est presque aussi importante qu'une bonne conception de domaine. Une topologie de site bien pensée réduit le trafic réseau associé aux AD, garantit que les utilisateurs s'authentifient par l'intermédiaire d'un DC (domain controller) proche, et rend plus prévisible le temps de réplication d'un objet dans toute l'entreprise...Les sites AD jouent aussi un autre rôle important, même s'il est moins connu et moins direct : ils influencent le basculement des DC client. Le basculement est l'opération par laquelle un client se connecte à  un autre DC quand le DC courant du client est défaillant. Par conséquent, une bonne topologie de sites AD est celle où l'on peut choisir n'importe quel emplacement sur le réseau, marquer un DC comme indisponible et faire que les clients de ce site choisissent le meilleur DC suivant disponible
Pourquoi est-il si important de concevoir en vue du basculement des DC ? La sélection du DC d'un client est un facteur important dans le temps de connexion de l'utilisateur et dans son temps de réponse perçu. Ainsi, la plupart des sociétés utilisent des scripts de logon et la distance sur le réseau entre le DC authentifiant et le client, a une grande influence sur la vitesse d'exécution du script de logon. Considérons aussi que Microsoft Exchange 2000 Server et ses clients sont de gros utilisateurs de l'AD Global Catalog (GC). Par conséquent, si l'on n'a pas la main heureuse en choisissant le DC qui héberge le GC, ce sera au détriment du temps de réponse e-mail du client.
Avant de commencer à  concevoir pour le basculement du DC, il faut savoir comment un client sélectionne son DC, un choix connu sous le nom de processus de localisation de DC. Quand vous modélisez le basculement des DC (en faisant comme si les DC préférés n'étaient pas disponibles), vous suivez le processus de localisation des DC pour déterminer quels DC de remplacement le client choisira. Dans l'idéal, quand un client Windows ne pourrait pas contacter un DC local (c'est-à -dire sur site), il utiliserait les coûts des liens de site dans la topologie de sites AD pour déterminer le site suivant le plus proche et tenter d'y contacter un DC. Si les DC de ce site n'étaient pas disponibles, le client rechercherait le site suivant le plus proche et essaierait à  nouveau, bouclant ainsi jusqu'à  ce qu'il trouve un DC. Malheureusement, le processus de localisation de DC n'en est pas encore à  ce stade. Dans Windows Server 2003 et Win2K, le client demande une liste des DC présents dans son site et son domaine. Si ces DC ne sont pas disponibles, le client demande la liste de tous les DC de son domaine. Pour plus d'informations sur le processus de localisation de DC Windows 2003 et Win2K, voir l'article « Topologie de l'authentification », Windows & .Net Magazine mai 2003 ou www.itpro.fr

Point de décision Windows 2003

par Jeremy Moskowitz - Mis en ligne le 15/09/2004 - Publié en Janvier 2004

Ce questionnaire vous aidera dans votre décision : rester avec Win2K ou faire le saut à  Windows 2003

Le successeur de Windows 2000 a porté trois noms : Windows 2002, Windows .NET (Win.NET) Server et l'actuel Windows Server 2003. Dans la confusion du changement de nomenclature et des ajouts et retrait de fonctions de dernière minute, vous vous demandez peut-être si ça vaut la peine de passer à  Windows 2003...Certains experts considèrent que Windows 2003 est une simple « étape intermédiaire » en avant ; pour d'autres, c'est la « prochaine génération ». Qui croire ?
Si vous êtes sur le point de commencer un déploiement Win2K, devriez-vous foncer ou bien vous regrouper et jeter un coup d'oeil à  Windows 2003? Dans un monde idéal, vous devriez être capable de déterminer facilement si Windows 2003 convient à  votre environnement. Bien sûr, Windows 2003 est riche de superbes fonctions, comme le support d'un milliard d'objets AD (Active Directory), une sécurité plus rigoureuse et beaucoup de nouveaux utilitaires ligne de commande. Mais qu'en est-il des améliorations apportées aux principales fonctions de l'OS, comme Microsoft IIS, le support du clustering, et Terminal Services ? Sachant comment vous utilisez votre réseau aujourd'hui, utiliserez-vous réellement ces fonctions améliorées ?

Gérer les comptes utilisateur, 2^ème partie

par Ethan Wilansky - Mis en ligne le 12/01/2005 - Publié en Mars 2004

Le fonctionnement interne de 3U

Dans la 1ère partie de « Gérer les comptes utilisateur », j'ai présenté mon User Update Utility (3U), un utilitaire graphique à  la fois léger, simple et puissant pour maintenir des comptes utilisateur dans un domaine AD (Active Directory). J'ai créé cet outil pour administrer les comptes utilisateur dans un domaine AD validé pour Exchange 2000 Server. Mais je l'ai modifié depuis afin qu'il puisse administrer des comptes utilisateur dans des domaines AD sans Exchange 2000 (ou Exchange Server 2003) ...Dans la 1ère partie, j'ai décrit les divers fichiers de 3U, les préparations pour l'utilisation de 3U, et l'exécution de l'utilitaire. Ensuite, j'ai entamé l'exploration du code de 3U en décrivant comment il se connecte à  AD et construit l'interface. Dans ce second article, je poursuis l'exploration du code en décrivant la manière dont 3U prend à  son compte l'administration des comptes utilisateur en appelant les diverses sousroutines dans UserUpadte.hta, Results.htm et PropPage.htm.

Actualités Windows NT / 2000 – Semaine 51 – 2004

Toutes les Actualités du 13 au 19 Décembre 2004

Actualités Windows NT / 2000 – Semaine 49 – 2004

Toutes les Actualités du 29 Novembre au 5 Décembre 2004

Reprise après sinistre avec DFS

par Douglas Toombs - Mis en ligne le 8/12/2004 - Publié en Novembre 2003

Comment répliquer fiablement certains types de données en prévision du pire

En matière de planning de reprise après sinistre, la question est : qu'estce qui constitue un sinistre ou une catastrophe ? Même si la réponse semble évidente, il est difficile de recenser tout ce qui pourrait représenter un sinistre. Les catastrophes naturelles comme les incendies, les tremblements de terre, les inondations, sont faciles à  identifier. Mais le danger peut aussi venir de circonstances inhabituelles ...Par exemple, j'habite dans la région de Washington et ai rencontré des dizaines de personnes dont la productivité de ces deux dernières années a été affectée par des quarantaines et des évacuations dues à  la menace d'attaques terroristes, de guerre biologique ou de délinquance. Il est évident que la plupart des administrateurs IT qui planifient l'éventualité d'un sinistre ignorent ces genres de circonstances.
Après m'être entretenu avec des gens confrontés à  ces situations, j'ai forgé ma propre définition d'un sinistre : tout événement qui prive les utilisateurs professionnels des données de gestion pendant une durée inacceptable (parfois de façon permanente), mettant en danger la vie même de l'entreprise. Je reconnais que ma définition est très large : même un simple incident comme une panne de disque dur peut répondre à  ces critères. Toutefois, selon la quantité et le type de données concernées et la capacité de récupérer cette information en temps utile (si c'est possible), certaines entreprises pourraient facilement considérer une défaillance de disque dur comme un vrai sinistre. Pour vous aider à  mieux concevoir des solutions de reprise après sinistre, commencez à  envisager le planning de reprise comme le moyen de réduire le temps pendant lequel vos utilisateurs sont privés des données de gestion, pour quelque raison que ce soit. Voyons un exemple de scénario catastrophe pour voir comment Microsoft Dfs peut jouer un rôle dans votre plan de reprise après sinistre et vous aider à  réduire le temps nécessaire pour reconnecter les utilisateurs à  certains types de données.

Find Duplicates Wizard for SQL Server

Azlexica annonce Find Duplicates Wizard for SQL Server, logiciel qui permet d'effectuer une analyse dupliquée multi clés sur la base de données SQL Server 2000 ou 7.0, puis exporte le résultat dans le tableur.

Il effectue son processus directement sur le serveur, ainsi il n'est pas nécessaire d'envoyer les données sur le réseau pour l'analyse.