Life of an IT Pro Advisor @ Microsoft Canada

Les diapositives sont maintenant disponibles en français. Voici le lien pour le site de web ou tu peu les télécharger.
http://www.microsoft.com/technet/canada/wintertour2005/postevent/default.asp

J’ai aussi inclus le lien pour un article j’ai écrit ou il y a beaucoup de ressources et logicielles que j’ai utilisé pendant les séances.
http://blogs.msdn.com/rclaus/archive/2005/02/24/379540.aspx

Merci tout le monde pour un tourné de TechNet qui était vraiment « fun ». On va avoir un rencontre avec l’équipe pour décider comment améliorer la prochaine tournée. 

-------------

The slides have been available for a while on the post event web resource page. Here is a link to the official post event site.
http://www.microsoft.com/technet/canada/wintertour2005/postevent/default.asp

I’ve also included a link to an article that I published earlier in the tour that has links to all sorts of utilities and evaluation software you can download and try for yourself.
http://blogs.msdn.com/rclaus/archive/2005/02/24/379540.aspx

Thanks goes out to everyone for making this TechNet tour so fun. I had a great time and can’t wait to have a post tour pow-wow and discuss how to make the next one even better!

J’avais beaucoup de questions dans mon courriel électronique au sujet d’intégrer les nouveaux *.ADM fichier qui sont en place avec Windows XP SP2 dans une environnement Active Directory. Peut-être j’aurai beaucoup d’autre question maintenant que les personnes travaillent avec Windows Server 2003 SP1.  Les deux systèmes changes la longueur des « strings » au point qu’ils sont incompatibles avec un MMC qui est utilisé sur un system au niveau précédent de Windows XP SP2.

J’ai déjà écrit un article qui explique la méthode que les *.ADM fichier se mis a niveau automatiquement dans un environnement d’Active Directory et comment tu as besoin d’évaluer et choisir la procédure qui est correct pour votre environnement.  (La manière défaut fonctionne pour presque tous les gents)

Pour essayer de répondre au question la plus simple et le plus court que possible :
Si tu crée ou change un GPO avec un MMC sur un system de Windows XP SP2 ou Windows Server 2003 SP1, la réaction défaut est que les fichiers seront télécharger au Domain Controllers et en effet remplace les versions plus ancienne. Pour éviter les erreurs de « [strings] too long », toutes les systèmes utilisés pour gérer les GPO a besoin d’un patch pour mettre a niveau un DLL qui est utiliser par le MMC.

(Cette réponse est simple et court?)

Regarder l’article KB842933.  Il est trouvé ici.  Tu n’as pas besoin beaucoup d’analyse pour cette patch. Les systèmes n’ont pas besoin d’être redémarré après l’application du patch si tu fermes le MMC avant de commencer.  Seulement les systèmes utilisés pour gérer les GPO on a besoin du patch. Les systèmes au niveau de :

• Windows XP sans SP2
• Tous les systèmes Windows 2000 Professional
• Windows Server 2003 sans SP1
• Tous les systèmes Windows 2000 Server

Si tu décide de ne pas appliquer le patch – c’est OK – tu ne casse pas ton GPO si tu les changes avec un MMC plus ancien. Tu dois tous simplement « clicker » un vingtaine fois sur le « ok » bouton. ;-)

I've had a number of questions around the *.ADM templates that come with a Windows XP Service Pack 2 machine and what they do to the GPOs in an Active Directory Domain. With people using Server 2003 SP1 systems, I might get more questions being asked.  Both systems increase the length of strings beyond what the MMC console can take on a older OS (by older I mean PRE-XP-SP2).

I've already wirtten an article outlining the ADM template update process, how they get copied up to the domain controllers AND about how you need to choose the right process for your organization - default works great for almost all situations.

To make a long blog post shorter and to come to the point:
If you edit a GPO with an XP-SP2 or Server 2003 SP1 management console with the updated *.ADM templates, the default action is that the templates will be copied up to the Domain Controllers and overwrite the old ones. As a result of this action - all admin workstations (and servers) that are NOT XP-SP2 or Server 2003 SP1 need to be patched with the appropriate patch if they are going to be used to manage GPOs.

(that was short?)

You might want to read the details contained in Knowledge Base article 842933. It can be found here. Not to worry - no major testing require of this patch. No reboots are required (unless the GPO MMC or GPMC is open at the time of the patch - in which case, close it and patch again). Only the systems used to manage GPOs need to be patched. They apply to workstations that are running:

• Windows XP PRIOR to Service Pack 2
• All Windows 2000 Pro systems
• Windows Server 2003 PRIOR to SP1
• All Windows Server 2000 systems

 If you don't patch them - don't worry - you won't "break" your GPO by editing it with an older version of the console. You'll just have to be proficient at clicking 20 or so times on the OK button. ;-)

Le nom de domaine de DNS est fréquemment un bloc dans le processus de conception pour des personnes travaillant sur une migration d'AD. J'ai fait un certain nombre de « round tables » ou les discussions facilitées au sujet de ces matière et ce qui me surprise est que les gents le fait plus compliqués qu’ils on besoin. Étant un conseiller qui a fait un certain nombre de projet d'AD pour des clients avec les nombres d’usager de 200 à 27000 je l'ai vu tout. J'ai deux recommandations simples :

• Utilise le principle de KISS (Keep It Simple S{remplace le mot avec ton nom de choix})
• Fait le choix correctement un fois - et gardez-le.

La semaine passé, j'ai sorti pour le dîner (j'étais à Redmond pour une conférence technique) et une discussion a été soulevée au sujet du stratégies de DNS. Prenez un consultant en matière de stratégie d'entreprise, un consultant d’AD et un x-RedHat/Ingénieur d'oracle et quelques points intéressants obtiennent augmentés. Je ne vous dirai pas qui a soulevé quelle stratégie - je vous laisserai choisir:

Option 1 - Employez les mêmes noms internes et externes.
Si j’ai déjà achetez rickcompany.ca. et je l'emploi a l’extérieure, pourquoi pas employez a l'intérieure aussi? Humm... Maintenir 2 zone de DNS sur deux serveurs qui ne peut pas échangez l'information et devront être séparément contrôlés. Ceci pourrait sembler comme un bon principe de KISS et fortifier le « confort » des clients interne. En effet - il place beaucoup plus d’effort administratif sur les admins de DNS et ce n'est pas exactement « future proof » pour les besoins changeants d'affaires. Vous devrez manuellement ajouter les entrées externes dans votre zone interne. Vous devrez sélectivement ajouter les ressources internes à votre zone externe. Comment manipulerez-vous les ressources internes et externes quand c’est temps de changez a IPv6?

Oui – c’est vrai.  Je l'ai mise en application cette stratégie pour des clients - après qu'ils aient passé en revue tous les « pour et contre ». 

Option 2 - Employez un domaine secondaire délégué du domaine externe pour le domaine interne.
Si j’ai déjà achetez rickcompany.ca et je l'emploie a l’extérieur (je l'accueille sur un ensemble de serveurs moi-même ou mon service d’Internet), je crée un domaine secondaire a l’intérieur seulement qui pourrait s'appeler corp.rickcompany.ca ou ad.rickcompany.ca ou n’importequoi.rickcompany.ca. Puisque ce domaine secondaire est seulement maintenu a l’intérieur sur les serveurs internes de DNS, il ne peut pas être accidentellement placé sur les serveurs a extérieur. Les clients et les serveurs feraient partie du domaine secondaire interne de rickcompany.ca et fonction normalement dans un environnement d'AD.  Si vous aviez déjà une grande (ou petite) zone de DNS rickcompany.ca, les ressources pourraient être transférés à l’intérieur utilisant un zone secondaire. C'est le plus facile à contrôler, puisque vous commandez la zone et ne devez pas s'inquiéter de ce qui est à l'intérieur et dehors. Vous « futureproof » également votre réseau, puisque vous avez des noms uniques à l'intérieur et a l’extérieur. Si vos clients internes ont la mauvaise habitude d’identifier les ressources pas entièrement qualifier de DNS,  vous pouvez ajouter rickcompany.ca à votre liste de domaines de recherche pour assurer le nom résolution approprié.

Option 3 - Employez un domaine interne non standard. (Dustin Norman m'a rappelé celui-ci).
J'ai employé celui-ci à seulement une occasion. Je vous avertis que vous devriez employer celui-ci avec prudence - comme il limite sévèrement votre capacité de contrôler facilement les ressources internes que vous voulez faire accessible à l’extérieur. Si vous choisissez d'employer rickcompany.interne ou rickcompany.local pour votre Domaine interne de DNS, vous garantissez pratiquement que vos centres serveurs internes ne seront jamais résolubles du monde extérieur.  Il n'est pas dans généralement de meilleures habitudes recommandées d'employer ce type de domaine non standard de DNS sans regarder toutes les implications.

Je terminerai cette conversation en disant – comprenez toutes les implications de choisir le nom du domaine de DNS. Choisissez seulement après que vous avez évalué tout les options. Vous avez besoin d'un stratégie en bon état pour votre nom de domaine DNS et comment cela fonctionne afin d'assurer une base forte pour « Active Directory ».

Comment est-ce que je réponds quand quelqu'un me pose la question de DNS? "Ca dépend....."

Voici un lien à la discussion 2003 de guide déploiement des serveur DNS de Windows
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp