Analyse des relais Exchange
par Joseph Neubauer - Mis en ligne le 29/03/06 - Publié en Mars 2005
De plus en plus d’organisations mettent en place des stratégies qui requièrent des évaluations de la sécurité et des vulnérabilités au niveau des serveurs et systèmes avant leur déploiement sur le réseau. Nombre de ces stratégies nécessitent des outils d’audit afin de rechercher des exploitations de vulnérabilité sur les serveurs, de confirmer les versions de correctifs, de fournir des conseils de verrouillage de la sécurité, etc. Pour les serveurs Exchange Server 2003 et Exchange 2000 Server, l’une des vulnérabilités à prendre très au sérieux et la notion de « relais ouvert ».Qu’est-ce qu’un relais ouvert ? Une fonctionnalité de SMTP permet à un serveur de faire office d’intermédiaire et d’accepter des messages pour le compte de la destination finale. Ce serveur retransmet (ou relaie) ensuite les messages vers la destination en question. Dans Exchange, vous pouvez configurer les serveurs de telle sorte que certains ordinateurs et utilisateurs puissent relayer le courrier. Toutefois, lorsque des problèmes de configuration surviennent et que tout un chacun peut utiliser le système pour relayer du courrier, on parle de relais ouvert. Cette situation est dangereuse pour au moins deux raisons : premièrement, SMTP est intrinsèquement non sécurisé, ce qui permet d’usurper ou de contrefaire facilement l’identité de l’expéditeur dans un message. Récemment, la prolifération de virus tels que Bagel a montré comment la contrefaçon de l’identité de l’expéditeur peut être source de confusion et accroître la charge de travail. Un relais ouvert amplifie le problème car un message contrefait ajoute un certain niveau d’authenticité. En effet, le message semble provenir d’un serveur du domaine de l’expéditeur spécifié.
Deuxièmement, les spammeurs se servent fréquemment des relais ouverts pour propager leur charge utile. Dans ce type de situation, les ressources de votre serveur sont détournées du traitement du trafic de messagerie de votre organisation. Outre le détournement des ressources et la gêne occasionnée dans la remise des courriers, ce phénomène risque d’entraîner des pertes d’activité sur le long terme. L’utilisation de logiciels antispam et de listes noires telles que MAPS (http://www.mailabuse.com) peut aboutir au rejet de tous les courriers légitimes de votre domaine, du fait de sa réputation de relais ouvert. Un relais ouvert peut entraver la capacité commerciale de votre organisation et ternir son image de marque.
Si les relais ouverts constituent une telle menace, pourquoi faire en sorte que vos serveurs relaient le courrier ? En règle générale, vous autorisez la fonction de relais lorsqu’une application doit envoyer du courrier SMTP mais que vous n’avez pas la possibilité de déterminer le moyen de transmettre le message à sa destination. Vous configurez l’application afin de transférer le message directement à votre serveur relais, et ce dernier utilise le routage SMTP pour remettre le message à ses destinataires. Les clients POP et MAP constituent des exemples de ces types d’applications. C’est également le cas d’un formulaire de serveur Web qui envoie des configurations d’e-mail lors du téléchargement d’informations. Dans certaines situations, notamment la conception d’une application de serveur Web, vous pourriez développer l’application de telle sorte qu’elle utilise plutôt MAPI (Messaging API) au lieu de SMPT, éliminant ainsi le besoin de relais. Mais la tendance est plutôt à l’utilisation de protocoles standard (par ex., SMPT) et non à leur mise à l’écart.
Dans le cas de POP et d’IMAP, le relais est nécessaire car ces deux protocoles ne sont pas prévus pour envoyer des courriers, mais plutôt pour les récupérer des boîtes aux lettres. Pour envoyer des courriers, les protocoles POP et IMAP doivent être couplés à SMTP et le client doit être configuré avec le nom d’un serveur autorisant la fonction de relais. La prise en charge du relais pour ces applications ne signifie pas que votre serveur deviendra obligatoirement
Réactiver facilement les utilisateurs NetServer désactivés
par Chuck Lundgren, Mis en ligne le 15/O3/2006 - Publié en Septembre 2005
L’iSeries NetServer permet aux utilisateurs de PC d’associer un lecteur ou une imprimante à l’iSeries. Très utile, cette fonction pose cependant quelques difficultés aux administrateurs système, qui doivent se préoccuper de la propagation des virus PC via les shares iSeries, des pépins de connectivité et des problèmes de performances. Il est fréquent que des utilisateurs trouvent leur accès désactivé à cause de mots de passe modifiés, de mots de passe incorrects et autres. L’administrateur système doit alors intervenir pour remettre dans le jeu les utilisateurs NetServer désactivés.IBM propose quelques moyens (certains plus commodes que d’autres) pour obtenir la liste des utilisateurs NetServer désactivés. Le procédé le moins commode consiste à rechercher le message CPIB682 – le message d’alerte signalant un utilisateur NetServer désactivé. Vous utilisez la commande WRKSPLF (Work with Spooled Files) :
WRKSPLF QSYSOPR
Vous pourriez aussi utiliser la commande DSPLOG (Display Log):
DSPLOG MSGID(CPIB682)
Quand vous repérez un utilisateur NetServer désactivé dans les journaux, vous pouvez émettre la commande CHGUSRPRF (Change User Profile) :
CHGUSRPRF profile-name
où profile-name est le nom de l’utilisateur NetServer désactivé. Il n’est pas nécessaire de changer le profil parce que le simple fait d’exécuter la commande réactive l’accès à NetServer.
Pour lister les utilisateurs NetServer désactivés, iSeries Navigator propose une méthode plus commode. Dans iSeries Navigator, cliquez sur My Connections|Network |Servers|TCP/IP puis double cliquez sur le noeud iSeries NetServer. Ensuite, faites un clic droit sur iSeries NetServer et sélectionnez l’option pour les ID utilisateur désactivés, pour voir la liste des utilisateurs NetServer désactivés. Il est ensuite très facile de réactiver les utilisateurs dans cette fenêtre.
Il existe une alternative écran passif à la méthode iSeries Navigator : elle consiste à utiliser le menu NETS dans la bibliothèque QUSRTOOL. Après avoir entré GO NETS sur la ligne de commande, sélectionnez Work with NetServer Users dans le menu, pour afficher la liste de tous les utilisateurs NetServer désactivés. Pour réactiver les profils affichés, appuyez sur F7.
L’utilitaire Activate NetServer User (ActNetUsr) de cet article offre une autre méthode écran passif pour réactiver les utilisateurs NetServer. Il a pour autre avantage de montrer comment mettre en oeuvre les API QZLSOLST (Open List of Server Information) et QZLSCHSI (Changer Server Information) qui permettent d’extraire des informations serveur et de les modifier.
L’utilitaire ActNetUsr (qui n’a pas de paramètres) s’exécute dans l’ordre suivant :
- Premièrement, il utilise l’API QZLSOLST pour extraire une liste des utilisateurs NetServer désactivés.
- Pour chaque utilisateur extrait, le programme envoie le message d’interrogation suivant au job actif exécutant
ActNetUsr :
NetServer user user-name disabled.
Enable SetServer user (Y=Yes)?
- Si Y est spécifié, le programme appelle l’API QZLSCHSI pour activer l’utilisateur NetServer spécifié.
- Une fois tous les utilisateurs traités, le programme envoie un message de bonne fin :
NetServer user activation completed.
A noter que l’API QZLSOLST fournit beaucoup plus d’informations sur le serveur que cet utilitaire n’en utilise : share, configuration, session, statistiques, connexion et autres. L’API QZLSCHSI vous permet de changer beaucoup moins d’informations que l’API QZLSOLST n’en affiche. Le changement de certaines Lire l'article
Maîtriser les stratégies de groupe
par Kathy Ivens - Mis en ligne le 22/02/06 - Publié en Octobre 2004
L’administration d’un environnement Windows est une tâche ardue. Des fonctions comme les stratégies de groupe, qui permettent aux administrateurs de contrôler les clients d’un domaine (ordinateurs et utilisateurs), sont fort utiles. Mais nombreux sont les administrateurs qui n’appliquent les stratégies de sécurité qu’après que certains événements les y obligent. Exemple d’un tel événement : un utilisateur qui bouleverse complètement la configuration de l’ordinateur ou qui modifie un paramètre en entraînant des problèmes pour l’ensemble du domaine.Quand un administrateur applique des stratégies au coup par coup, il s’en suit souvent un magma de nombreuses stratégies. Un trop grand nombre de stratégies peut augmenter le temps de connexion des machines client, au grand dam des utilisateurs. Cela peut aussi entraîner des conflits de stratégie présentant une double inconvénient : certains utilisateurs ne peuvent pas effectuer correctement leur travail et d’autres peuvent effectuer, à tort, des tâches qui affectent le domaine. On établit alors à la hâte une stratégie de plus pour corriger l’erreur, ce qui ne fait qu’aggraver la situation.
On peut bien entendu établir des stratégies de manière parfaitement ordonnée. En anticipant et en faisant le nécessaire pour réduire le nombre de stratégies nécessaires, vous pouvez éviter beaucoup des pièges qui guettent les administrateurs dans l’application des stratégies.
Trucs & Astuces : La commande Netsh
Les trucs & astuces de la semaine du 30 janvier au 5 février 2006
Lire l'article
News iSeries – Semaine 2 – 2006
Toutes les actualités de la semaine du 9 au 15 Janvier 2006
Lire l'article
Les services Web peuvent-ils vous servir?
par Aaron Bartell - Mis en ligne le 07/12/2005 - Publié en Mars 2005
Vous vous demandez peut-être
« Pourquoi parle-t-on autant des
services Web dans le monde de la
technologie ? Après tout, il y a belle
lurette que nous faisons du développement
orienté service modulaire et
que nous nous connectons à
d'autres systèmes distants. Il y a tellement
de moyens différents de
communiquer avec l'iSeries (DDM,
DRDA, FTP, ODBC, JDBC, « raw sockets
»). Devons-nous vraiment nous
encombrer d'une technologie de
plus ? Pourquoi ne pas simplement
adopter l'une des méthodes de communication
existantes et continuer à
progresser ? Pourquoi les services
Web ? Pourquoi maintenant ? Pourquoi
toutes ces nouvelles technologies
et nouveaux standards déroutants
? »
Protection de l’IFS contre les virus
par Phil Coulthard, Mis en ligne le 12/04/2006 - Publié en Novembre 2005
Pendant longtemps, les utilisateurs iSeries ont fait confiance à i5/OS pour repousser les virus, les chevaux de Troie et autres vers, qui assaillent les systèmes Microsoft Windows. Et cela, en grande partie grâce à l’architecture d’authentification basée sur la capacité i5/OS. Bien que cette architecture soit très « mature » (ses origines remontent au S/38 dans les années 1970) et présente parfois quelques faiblesses (que l’IBM traite rapidement), aucun virus n’est jamais parvenu à infecter un programme ou objet natif iSeries.En i5/OS, un objet fichier ne peut pas imiter un programme exécutable et un programme ne peut pas modifier le code binaire d’un autre : une fois créé, un programme est immuable. De plus, les programmes ne peuvent accéder aux objets que par des interfaces sûres et bien définies, et pas directement par l’intermédiaire d’une adresse mémoire ou disque. En matière d’objets natifs, i5/OS rend inopérantes les techniques habituelles des auteurs de virus.
Dans ce propos, le terme vedette est l’adjectif « natif ». La robuste sécurité objet de l’iSeries ne s’étend pas jusqu’aux portions de l’IFS (integrated file system) – particulièrement les portions présentes dans les répertoires racine accessibles à distance par des postes de travail et des serveurs Windows porteurs de virus. Quand un système distant accède à l’IFS, il a le pouvoir d’infecter les fichiers IFS avec un code viral. Les systèmes non infectés qui liront ultérieurement les fichiers infectés pourront eux-mêmes être contaminés. Un virus peut ainsi se répandre dans un réseau d’entreprise en quelques minutes, causant des dégâts incalculables.
Jusqu’à la V5R3, la seule protection antivirus pour l’IFS était constituée de packages antivirus de type PC qui scrutaient la racine IFS à distance, en la traitant simplement comme un autre lecteur disque de PC. Malheureusement, pour pouvoir faire cela, le PC chargé du scanning doit posséder tous les droits objet sur l’IFS : un gros risque pour la sécurité. Le scanning proprement dit doit lire tout le contenu de l’IFS initialement, avec pour résultat de gros volumes de trafic réseau. Et, bien que les scans suivants puissent être limités aux seuls fichiers modifiés depuis le dernier scan, rien ne garantit qu’une infection ne surviendra pas et ne se répandra pas entre les scans.
Avec la V5R3, IBM fait bénéficier i5/OS de la puissance du scanning de virus natif. Moyennant de nouveaux attributs de répertoire et de fichier, valeurs système et programmes de sortie, l’iSeries fournit désormais des points de connexion pour les programmes antivirus tiers qui assurent la protection en temps réel de l’IFS, éliminant le risque d’infection entre des scans. Et comme la protection antivirus est native, elle ne gonfle pas le trafic sur le réseau. Mieux encore, les extensions antivirus i5/OS sont à la disposition de tous : développeurs antivirus commerciaux et non commerciaux. Il sera donc possible de porter un scanner antivirus open-source sur l’iSeries.
Il faut noter que la validation du scanning de virus V5R3 n’inclut pas le logiciel de scanning de virus et de réparation proprement dit. Il faut l’obtenir auprès d’un fournisseur tiers ou écrire le vôtre. Il existe un produit commercial disponible dès à présent – livré, en fait, dans le cadre de la V5R3 – qui permet de bénéficier immédiatement de la protection antivirus natif : StandGuard AV for V5R3 de Bytware. Il est fort probable que d’autres produits antivirus apparaîtront à l’avenir. Pour bien évaluer de tels produits, ou peut-être pour écrire le vôtre, vous devez comprendre les mécanismes de scan de virus de la V5R3.
Heureusement, les améliorations sont simples et vous les assimilerez rapidement. Il y a deux nouveaux attributs de fichier/répertoire, deux nouvelles valeurs système, et deux nouveaux points de sortie de programme. Quand vous
Sauvegarder et restaurer une base Exchange
par Pascal Creusot - Mis en ligne le 29/03/06 - Publié en Mars 2005
La messagerie est devenu au fil du temps un outil capital pour ne pas dire indispensable pour la vie de toutes les entreprises. De nombreux collaborateurs stockent leurs données au sein de la messagerie, et les messages échangés peuvent représenter des affaires ou des transactions pouvant atteindre des sommes importantes. Dans ce contexte, la sauvegarde et la restauration des données de la messagerie représentent donc un enjeu important pour les entreprises.
Impression
par Dan Riehl, Mis en ligne le 15/O3/2006 - Publié en Septembre 2005
PAA (Program Adoption of Authority) est une technique qui permet d’élever temporairement les autorités de certains utilisateurs pour leur permettre des actions normalement interdites par leur autorité naturelle. Par exemple, supposons que vous vouliez que les gens du help desk puissent redéfinir le mot de passe de l’utilisateur. C’est une fonction sensible pour laquelle le personnel du help desk a besoin de niveaux d’autorité supérieurs (*ALLOBJ, *SECADM, par exemple). Mais si vous octroyez ces hauts niveaux d’autorité aux profils utilisateur des servants du help desk, ils pourront en permanence toucher à vos données sensibles, une situation pour le moins dangereuse.Il faut dans ce cas un petit programme aux fonctions limitées permettant à de tels utilisateurs d’adopter la puissante autorité dont ils ont besoin pour réinitialiser le mot de passe. Dès que le programme adoptant se termine, le haut niveau d’autorité disparaît. C’est exactement ce qu’accomplit PAA.
PAA est une fonction utile que vous auriez tort d’ignorer. Tout en sachant que, dans de mauvaises mains, PAA peut servir de porte dérobée pour obtenir de hauts niveaux d’autorité sans la supervision et le contrôle appropriés.
Lors de mes évaluations des vulnérabilités sur OS/400, j’ai souvent constaté qu’un programme adoptant un haut niveau d’autorité avait été subrepticement créé sur le système et utilisé comme méthode d’infiltration d’un système de sécurité par ailleurs bien conçu. Grâce à l’un de ces programmes adoptants, un utilisateur avisé peut facilement s’octroyer l’autorité d’un utilisateur puissant, comme QSECOFR, et devenir virtuellement QSECOFR chaque fois qu’il le désire.
News iSeries – Semaine 7 – 2006
Toutes les actualités de la semaine du 13 au 19 Février 2006
Lire l'article
La programmation CGI et l’iSeries
par Bradley V. Stone Mis en ligne le 31/01/2006 - Publié en Juin 2005
Voilà plusieurs années déjà que la programmation CGI (Common Gateway Interface) se pratique sur l’iSeries. Depuis au moins la V3R2, IBM fournit des API grâce auxquelles les programmeurs peuvent créer des pages Web entièrement fonctionnelles, sans recourir à des solutions coûteuses et exigeantes en ressources.
Aujourd’hui plus que jamais, les entreprises recherchent le meilleur moyen de proposer des applications Web interactives à leurs clients et utilisateurs. Le choix est vaste, le marketing vante certains produits, et il s’en suit que la plupart des sites passent souvent à côté de la meilleure solution.
En utilisant les API déjà disponibles sur l’iSeries, directement ou par l’intermédiaire d’un utilitaire tierce partie, les programmeurs iSeries s’aperçoivent que la technologie la mieux adaptée à leur cas est précisément celle qu’IBM songe à supprimer.
Trucs & Astuces : iSeries Access for Windows
Les trucs & astuces de la semaine du 9 au 15 Janvier 2006
Lire l'article
Publication de SQL Server dans Active Directory
par Chad Miller - Mis en ligne le 07/12/2005 - Publié en Décembre 2004
Vous avez peut-être remarqué la présence de l'onglet Active Directory dans la boîte
de dialogue SQL Server Properties de la console Enterprise Manager et vous vous
être peut-être interrogé sur le rapport existant entre Active Directory (AD) et SQL
Server ainsi que sur l'avantage d'ajouter SQL Server avec ses bases de données à
AD. Les services réseau tels que les serveurs de fichiers et d'impression se servent
d'Active Directory pour publier et stocker des informations relatives aux ressources
qu'ils proposent. Celui-ci contient une liste des comptes utilisateur et un annuaire
des ressources réseau disponibles.
Conseils et astuces pour PDM et SEU
par Jef Sutherland, Mis en ligne le 05/04/2006 - Publié en Octobre 2005
Même après plusieurs années d’utilisation d’une application, celle-ci recèle peut-être des fonctions inutilisées et susceptibles de l’améliorer. J’imagine que les développeurs compétents en PDM et SEU ont trouvé la plupart de ces fonctions cachées. Si vous n’avez pas encore confié votre développement à WDSc (WebSphere Development Studio Client), le moment est peut-être venu d’explorer quelques trésors cachés de PDM et de SEU. Examinons donc quelques astuces et techniques qui réjouiront même les programmeurs les plus chevronnés.
Application iSeries : modularisation
par Sharon L. Hoffman, Mis en ligne le 29/O3/2006 - Publié en Octobre 2005
La modularisation, ou programmation modulaire, organise le code en composantes fonctionnelles assorties d’interfaces clairement définies. C’est ainsi qu’avec ILE RPG, on peut organiser le code en membres /Copy, sous-routines et procédures appelables, ainsi qu’en modules, programmes de service et objets programme, pour s’en tenir aux principaux. Si l’on pratique la programmation modulaire, les changements d’une composante ont peu ou pas d’effet sur les autres parties d’une application. Un bon code modulaire facilite donc la modification des applications quand les exigences de l’entreprise changent. Mais la modularisation permet également de mélanger et de combiner des langages, en choisissant le meilleur outil pour chaque tâche. Enfin, elle est le premier pas important dans des projets comportant des interfaces de type navigateur et pratiquant l’extraction de données sur plates-formes hétérogènes.D’une manière générale, plus le code est modulaire et plus il est facile à maintenir. Mais il arrive parfois que les avantages engendrés par la segmentation du code soient contrebalancés par la complexité de la communication entre les composantes. On admet généralement qu’un code à couplage étroit est plus performant que des modèles plus modulaires. Or, une application modulaire bien conçue peut s’avérer plus performante, particulièrement dans un contexte réseau. Par conséquent, pour trouver la meilleure solution pour une situation donnée, il faut mettre dans la balance ces facteurs ainsi que les compétences des développeurs et la structure des applications existantes.
Pour vous aider à prendre ces décisions, la section suivante explore les techniques de modularisation en RPG et SQL applicables à un environnement applicatif iSeries classique. (Bien qu’il ne soit question ici que de RPG, les concepts valent aussi pour Cobol, CL et autres langages ILE.)
Gestion des files d’attente de messages Exchange Server 2003
par Mike Daugherty - Mis en ligne le 15/03/06- Publié en Janvier 2005
Tous les environnements Exchange Server 2003 sont constitués d’un ensemble de processus coopératifs, fonctionnant sur différents systèmes. Lors du transfert d’un message d’un processus à un autre, Exchange place souvent lesdits messages en file d’attente jusqu’à ce que le processus destinataire puisse le traiter. Par exemple, le serveur virtuel SMTP Exchange peut mettre en file d’attente les messages jusqu’à ce que le serveur virtuel effectue la recherche dans l’annuaire ou que le moteur de routage détermine le prochain saut (ou tronçon) approprié pour le message. Parfois, les processus émetteur et destinataire sont situés sur le même système, parfois ils résident sur des systèmes distincts. Tous les connecteurs, tels que ceux pour IBM Lotus Notes, Novell GroupWise, SMTP et X.400, placent en file d’attente les messages jusqu’à ce qu’Exchange établisse les connexions réseau avec les processus de messagerie s’exécutant sur d’autres systèmes.Microsoft a amélioré l’affichage des files d’attente pour Exchange 2003 en supprimant le besoin de se placer sous chaque serveur virtuel pour visualiser ses files d’attente. Le Gestionnaire système Exchange (ESM, Exchange System Manager) de la version 2003 inclut un affichage commun permettant de gérer facilement les files d’attente et les messages qu’elles contiennent. Vous pouvez employer l’affichage de file d’attente pour les serveurs virtuels SMTP et les connecteurs Exchange.
Le fait d’employer l’Analyseur de performances (Performance Monitor) afin de suivre le nombre d’entrées dans les files d’attente constitue l’une des meilleures méthodes pour détecter les problèmes potentiels de transport des messages. Lorsque l’Analyseur de performances indique qu’une file d’attente est plus volumineuse que ce qu’elle est censée être, vous pouvez recourir à ESM pour visualiser les messages qu’elle contient et déterminer, le cas échéant, s’il faut agir afin de remédier au problème. Les raisons pour lesquelles une file d’attente peut être plus volumineuse que prévu sont multiples : un message de très grande taille peut être en tête de file bloquer les autres jusqu’à ce qu’il soit remis, le message en tête de file d’attente peut avoir un problème qui empêche sa remise ou vous pouvez avoir tout simplement une augmentation temporaire du trafic des messages. Tant que vous n’avez pas examiné les entrées dans la file d’attente, vous ne pouvez pas déterminer la source du problème. Si celui-ci est dû à un message en particulier, vous pouvez le supprimer de la file d’attente et le renvoyer à l’expéditeur avec un rapport de non-remise (NDR).
N’attendez cependant pas d’avoir un problème pour examiner les files d’attente de messages. Une file d’attente sauvegardée peut être un indicateur préalable d’un problème système ou réseau important. Lorsque l’état d’une file d’attente ou d’un message indique un problème possible, les informations de file d’attente peuvent vous aider à identifier la source de l’incident. Nous allons, dans cet article, examiner les types de files d’attente de messages Exchange 2003, les outils disponibles pour surveiller et gérer les files d’attente, ainsi que la manière d’utiliser ces outils afin d’identifier et de résoudre les problèmes courants associés aux messages en file d’attente.
Archive Manager 3.0
Quest Software, Inc. annonce la disponibilité de Archive Manager 3.0, une nouvelle solution d’archivage intelligent des courriers électroniques basée sur la technologie de AfterMail Limited, éditeur récemment racheté par Quest Software.
Archive Manager 3.0 capture, indexe et archive les données de messagerie, facilitant la gestion des boîtes aux lettres, le partage des connaissances et la mise en conformité avec les obligations réglementaires de traçabilité et d’auditabilité des correspondances.
Lire l'article
Un bref coup d’oeil aux interfaces utilisateur
par Jef Sutherland Mis en ligne le 31/01/2006 - Publié en Juin 2005
A combien d’interfaces utilisateur (UI, user interfaces) avez-vous affaire chaque jour ? Réveils, montres, cafetières, fours à micro-ondes, téléphones, répondeurs, claviers d’accès et voitures, ne sont que quelques-uns des appareils munis d’interfaces qu’on utilise quotidiennement sans y prêter attention. Et ce avant même de nous asseoir à notre bureau, d’allumer l’ordinateur et de regarder l’écran.
La manière dont les dispositifs électroniques présentent l’information aux utilisateurs décide souvent du destin et de l’utilité de l’appareil. Il en va de même pour nos applications.En tant que développeurs, nous pouvons avoir la meilleure logique et les meilleures routines de traitement sous l’interface utilisateur, mais si celle-ci n’obtient pas la bonne information de nos utilisateurs ou, à l’inverse, ne la leur présente pas de manière claire et compréhensible, l’investissement applicatif est gaspillé. Parce qu’elle est primordiale, l’interface utilisateur ne doit pas être prise à la légère.
Nouveaux Produits Exchange – Semaine 2 – 2006
Les nouveaux produits de Janvier 2006 pour Exchange Server
Lire l'article
MS Analysis Services : Hors des sentiers battus
par William Sheldon - Mis en ligne le 07/12/2005 - Publié en Décembre 2004
PARTIE I : LES « CUSTOM MEMBERS »
MS Analysis Services recèle un grand nombre de fonctionnalités avancées.
Certaines peuvent sembler gadget de prime abord mais s'avèrent en fait particulièrement
utiles dans la pratique.
Cette série d'articles s'adresse en priorité à ceux d'entre vous qui utilisent déjà
MS Analysis Services et qui souhaitent élargir
leur connaissance du produit. Il permettra
également à ceux qui découvrent
l'OLAP avec les technologies Microsoft de
se familiariser avec de nouveaux concepts.
Il ne s'agit pas bien entendu d'un exposé
complet sur les fonctionnalités avancées
de MS Analysis Services (la documentation
en ligne livrée avec le produit est
faite pour cela) mais d'un retour d'expérience
sur l'utilisation concrète de certaines fonctions clés du produit qui sont souvent
sous-estimées ou tout simplement méconnues.
Les plus consultés sur iTPro.fr
- Le Club EBIOS, une communauté dédiée à la gestion des risques autour de la méthode EBIOS
- La difficile mise en conformité avec les réglementations pour les entreprises françaises
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
