Lors de la configuration d’SQL Server 2008 R2 reporting Services, vous pourriez rencontrer l’erreur :”Le serveur de rapports ne peut pas déchiffrer la clé symétrique …”

Lire la suite

Il est possible que vous rencontriez l’erreur suivante lors de l’installation d’une seconde instance sur un server SQL Server 2008 R2 :

The SQL Server product key is not valid. To proceed, re-enter the product key values from the Certificate of Authenticity (COA) or SQL Server packaging.
Error code 0x84B40000.

Lire la suite

Les certificats sont de plus en plus présents dans nos environnements, signature de mail, chiffrement de fichiers, authentification, …

Après avoir mis en place notre PKI, nous allons voir comment déployer de façon automatisé des certificats aux utilisateur de notre domaine. Ce type de déploiement permet par exemple d’implémenter les fonctionnalités chiffrement de mails ou de gestion d’accès réseau.

Lire la suite

Les certificats sont de plus en plus présents dans nos environnements, signature de mail, chiffrement de fichiers, authentification, …

Après avoir mis en place notre PKI, nous allons voir comment déployer de façon automatisé des certificats sur les postes clients de notre domaine. Ce type de déploiement permet par exemple d’implémenter les fonctionnalités de communications HTTPS sous SCCM 2012.

Lire la suite

Les certificats sont de plus en plus présents dans nos environnements, signature de mail, chiffrement de fichiers, authentification, … avant d’implémenter toutes ces fonctionnalités, un élément d’infrastructure est requis : La PKI pour Public Key Infrastructure ou Infrastructure à Clés Publiques.

Nous allons aborder au cours de ce post et des posts suivants la mise en œuvre d’une telle infrastructure sur Windows Server 2008 R2.

Lire la suite

Lorsque vous réinstallez Windows Server Updates Services sur Windows Server 2008 (R2) vous rencontrez très certainement l’erreur suivante :

The update could not be found. Either the update is not applicable to this computer or the update no longer exists. Either the update is not applicable to this computer or the update no longer exists. Verify that the update still exists and applicable to this computer form your WSUS server or Windows Update. Verify that the update still exists and applicable to this computer form your WSUS server or Windows Update.

Lire la suite

Windows Server 2008 R2 ne date pas d’aujourd’hui, mais Microsoft Press nous propose un eBook gratuit “Introducing Windows Server 2008 R2″ qui pourrait toujours rendre service !

Lire la suite

L’Offline Domain Join est un nouveau processus d’ajout de machine (Windows 7 ou Server 2008 R2 ) à un domaine Active Directory et ce, sans contact avec le contrôleur de domaine.

L’implémentation de l’Offline Domaine Join passe par un nouvel outil nommé « DJoin.exe ». Cet outil permet de provisionner un compte ordinateur au sein d’un Domaine Active Directory Domain Services.

Retrouvez ci-dessous les explications nécessaires à l’implémentation de cette nouvelle fonctionnalité !

Quels prérequis ?

Djoin.exe peut être exécute uniquement sur des machines Windows 7 ou Windows Server 2008 R2.

Par cela, comprenez que l’ordinateur que vous souhaitez ajouter au domaine doit être une machine Windows 7 ou Windows Server 2008 R2 et que la machine qui vous permettra de provisionner la nouvelle machine devra exécuter Windows 7 ou Windows Server 2008 R2.

Par défaut, Djoin.exe cible le « premier » contrôleur de domaine exécutant Windows Server 2008 R2. Sinon, l’attribut /downlevel permettra de cibler un contrôleur de domaine exécutant une version antérieure dans le cas ou votre site ne serait pas pourvu de DC 2008 R2.

Notez également qu’afin d’exécuter cette commande, vous devez être membre du groupe des administrateurs du domaine ou avoir les droits requis à l’ajout de machines au domaine.

Offline Domain Join, le processus.

Commencez par générer les métadonnées du compte ordinateur à ajouter (depuis n’importe quel poste W7 ou WS2008 R2 membre du domaine). Les métadonnées seront générées sous la forme d’un fichier texte que vous spécifierez en tant qu’attribut de la commande DJoin.

La commande à exécuter est sous la forme suivante :

djoin /provision /domain <em>domain to be joined </em>/machine <em>name of the destination computer </em>/savefile MetaData.txt

Une fois cette commande exécutée et les métadonnées générée, exécutez, sur l’ordinateur à joindre au domaine, la commande suivante en passant en parametres le fichier txt généré par la commande précédente :

djoin /requestODJ /loadfile MetaData.txt /windowspath %SystemRoot% /localos

Au redémarrage de la machine, celle-ci sera jointe au domaine.

Le fichier de métadonnées pourra également être « inclus » dans le fichier Unattend.xml utilisé lors de l’installation de votre système d’exploitation Windows7.

Détails sur la syntaxe d’utilisation de Djoin.exe :

djoin /provision /domain <domain_name> /machine <destination computer> /savefile <filename.txt> [/machineou <OU name>] [/dcname <name of domain controller>] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob]
djoin /requestodj /loadfile <filename.txt> /windowspath <path to the Windows directory of the offline image> /localos

à vous de jouer !

Baisser le niveau fonctionnel d’un domaine Active Directory ? Impossible ! Oui… enfin … non… je m’explique !

La rétrogradation du niveau fonctionnel est une tâche qui est, depuis les débuts d’Active directory… impossible, et ce entre autre à cause des attributs de schéma étendus de version en version, cependant il s’avère que grâce à l’arrivée de Powershell et forcément de Windows 2008 R2, il s’avère que cette tâche aussi impossible soit elle … puisse être effectuée (sous conditions … )

En effet, grâce à un jeu de commandes powershell vous allez pouvoir rétrograder votre niveau fonctionnel de domaine et de fôret de 2008 R2 vers 2008 et … pas plus … en effet cette possibilité ne concerne que ces niveaux fonctionnels et ce bien sûr à condition de ne pas avoir activé les nouvelles fonctionnalités du niveau 2008 R2 que sont par exemple la corbeille Active directory et ses diverses options de restauration d’objets.

Je vous ai parlé de commandes powershell ? Les voici ; premierement vous allez devoir rétrograder le niveau fonctionnel de votre fôret, pour cela, la commande suivante fera le travail pour vous :

Une fois le niveau fonctionnel de foret retrogradé, la commande suivante agira sur votre domaine 2008 R2 :

Et le tour est joué !

Comme vous le savez sans doute, depuis l’apparition du «Pare Feu de Windows avec options avancées de sécurité» sous Windows Server, il est désormais nécessaire d’effectuer une configuration préalable de celui-ci avant l’installation de certaines applications. SQL Server en faisant partie, nous allons donc voir la configuration à appliquer.

Le firewall de Windows Server autorisant par défaut les connexions sortantes (outbound) nous n’avons que la partie connexions entrantes à configurer (Inboud). Pour cela, rien de compliqué il suffit d’entrer dans la console de gestion de celui-ci, disponible dans les outils d’administration ou via composant MMC.
L’ouverture des ports nécessaires à l’exécution et à la communication vers notre Système de Gestion de Base de Données, se fera en créant des règles, pour cela, un clic droit sur « Règles de trafic entrant » vous permettra de créer les règles en question. Il vous suffira de créer les règles correspondantes aux ports et protocoles suivants pour obtenir la configuration firewall nécessaire au bon fonctionnement d’SQL Server.

Une fois cette configuration effectuée, lors de la vérification de la configuration firewall effectuée lors de l’installation de SQL Server un message d’avertissement vous indiquera que le firewall est actif et qu’une configuration pourrait être nécessaire … vous venez de la faire ! Félicitations !