Sylver SCHORGEN Blog's

Articles, astuces et news sur les technologies Microsoft et plus particulièrement tournant autour de Powershell
    • 27/9/2017

    [SharePoint] Microsoft Migration Tool

    Hi everyone,

    Microsoft annonced and published a tool to migrate data from a file share, SharePoint On-Premise or  CSV file (for bulk migration) to SharePoint Online ! That is terrific !

    I look forward to using this tool in one of my future migration and will keep you posted :-)

    The official article is here : https://techcommunity.microsoft.com/t5/SharePoint-Blog/Introducing-the-SharePoint-Migration-Tool-from-Microsoft/ba-p/109767

    • 26/9/2017

    [SharePoint] Outil de migration Microsoft

    Hello tout le monde,

    Microsoft a profité de l'Ignite afin d'annoncer un outil de migration vers SharePoint Online (depuis un partage réseau, un SharePoint On-Premise ou un fichier CSV pour un import en masse) :-)

    J'ai hâte de pouvoir tester cet outil afin de pouvoir vous en faire un retour !

    L'article officiel est par ici : https://techcommunity.microsoft.com/t5/SharePoint-Blog/Introducing-the-SharePoint-Migration-Tool-from-Microsoft/ba-p/109767

    • 23/9/2017

    [PowerShell - Domain Migration] SharePoint farm domain migration - User & Group migration

    Hi everyone,

    For one of my client, I had to migrate a SharePoint 2010 farm to a new domain. After reinstalling SharePoint from the beginning, I had to configure every service applications and migrate every content databases.

    This post is the first of a series dedicated to migrated SharePoint from one domain to another.

    The "problem" with the migrated database was that all user accounts and groups configured in SharePoint were from the old domain and not the new one. It was mandatory to migrate the old accounts to the new one (in the new domain). To do this task, I developped some PowerShell scripts. The script used to migrate users and group at the farm level is explained bellow. You can find this script here --> https://github.com/sschorgen/PowerShell/tree/master/SP10_Migrate-SPFromDomain

    This script was written and executed on SharePoint 2010.

    It is mandatory to create 2 CSV files :

    • 1 used to make the correspondence between the groups of the old domain and the new one
    • 1 used to make the correspondence between the usersof the old domain and the new one

    You can find an example of the group CSV file below :

    You can find an example of the user CSV file below :

    One part of the script is used to migrate groups :

    ForEach($Group in $Groups) {
    Write-Host " --- MIGRATING GROUP " $Group.oldDomain "-->" $Group.newDomain -ForegroundColor Yellow -NoNewLine
    $farm.MigrateGroup($Group.oldDomain, $Group.newDomain)
    Write-Host " OK !" -ForegroundColor Green
    }

    Another part of the script is used to migrate users :

    ForEach($User in $Users) {
    Write-Host " --- MIGRATING USER " $User.oldDomain "-->" $User.newDomain -ForegroundColor Yellow -NoNewLine
    $farm.MigrateUserAccount($User.oldDomain, $User.newDomain, $false)
    Write-Host " OK !" -ForegroundColor Green
    }

    Once you have created your 2 CSV files, you can execute this command :

    .\SP10_Migrate-SPUserAndGroupFromDomain.ps1 -UserMappingsCSV "D:\Scripts\users_to_migrate.csv" - GroupMappingsCSV "D:\Scripts\groups_to_migrate.csv"

    Happy migration ;)

    • 16/9/2017

    [PowerShell - Migration de domaine] Script de migration des groupes et utilisateurs de la ferme SharePoint

    Dans le cadre d'une migration SharePoint de domaine, nous avons réinstallé intégralement la ferme SharePoint 2010 d'un client dans un nouveau domaine. Suite à la réinstallation, il fallait reconfigurer l'intégralité des applications de service et restaurer les bases de données de contenu.

    Ce post est le premier d'une série dédiée à la migration SharePoint de domaine.

    Le "problème" avec les bases de données de contenu était les comptes utilisateurs et les groupes. En effet, suite à la restauration des bases de données de contenu, tous les comptes utilisateurs et les groupes étaient ceux de l'ancien domaine. Il était donc indispensable de migrer les utilisateurs et groupes afin de les faire "matcher" avec le nouveau domaine. Pour cela, plusieurs script ont été réalisés. Le script présenté ci-dessous permet de migrer tous les utilisateurs et groupes au niveau de la ferme SharePoint de destination, après avoir restauré les bases de données de contenu.

    Pour ce faire, j'ai réalisé un script PowerShell que vous pourrez trouver ici --> https://github.com/sschorgen/PowerShell/tree/master/SP10_Migrate-SPFromDomain

    Ce script a été conçu est exécuté sur SharePoint 2010.

    Il est indispensable de constituer 2 fichiers CSV :

    • 1 permettant d'effectuer la correspondance entre les groupes de l'ancien domaine et du nouveau
    • 1 permettant d'effectuer la correspondance entre les utilisateurs de l'ancien domaine et du nouveau

    Un exemple de fichier CSV contenant les correspondances groupes:

    Un exemple de fichier CSV contenant les correspondances utilisateurs :

    Le script est constitué d'une partie effectuant la migration des groupes :

    ForEach($Group in $Groups) {
    Write-Host " --- MIGRATING GROUP " $Group.oldDomain "-->" $Group.newDomain -ForegroundColor Yellow -NoNewLine
    $farm.MigrateGroup($Group.oldDomain, $Group.newDomain)
    Write-Host " OK !" -ForegroundColor Green
    }

    Et d'une autre partie responsable de la migration des utilisateurs :

    ForEach($User in $Users) {
    Write-Host " --- MIGRATING USER " $User.oldDomain "-->" $User.newDomain -ForegroundColor Yellow -NoNewLine
    $farm.MigrateUserAccount($User.oldDomain, $User.newDomain, $false)
    Write-Host " OK !" -ForegroundColor Green
    }

    Une fois les 2 fichiers CSV constitués, il ne vous reste plus qu'à exécuter la commande suivante :

    .\SP10_Migrate-SPUserAndGroupFromDomain.ps1 -UserMappingsCSV "D:\Scripts\users_to_migrate.csv" - GroupMappingsCSV "D:\Scripts\groups_to_migrate.csv"
    Bonne(s) migration(s) ;)
    Pour rappel : Ce post fait parti d'une série de plusieurs posts dédiés à la migration SharePoint de domaine
    • 12/9/2017

    [PowerShell] Deploy Work Folder Feature on Windows Server

    Hello everyone,

    Today I'll show you how to deploy the Windows Server Feature called "Work Folder" using PowerShell :

    1. Launch PowerShell as an administrator
    2. Run the following cmdlet : Install-WindowsFeature FS-SyncShareService

    • 31/8/2017

    [PowerShell] Déployer la fonctionnalité serveur dossiers de travail en utilisant PowerShell

    Hello tout le monde,

    Aujourd'hui une petite commande PowerShell permettant de déployer la fonctionnalité Windows Server "Dossier de travail" en PowerShell :

    1. Lancer une console PowerShell en tant qu'administrateur
    2. Exécuter la commande suivante : Install-WindowsFeature FS-SyncShareService

    • 16/8/2017

    [SHAREPOINT 2010 - INFOPATH] Error Data adapter failed during OnLoad: The remote server returned an error: (500) Internal Server Error

    Hi everybody,

    After a SharePoint 2010 domain migration, we had an error when creating or reading an Infopath form. The error said "An error occured while trying to connect to a Web Service". We had this error in the ULS logs :

    Data adapter failed during OnLoad: The remote server returned an error: (500) Internal Server Error.  Server was unable to process request. ---> Specified argument was out of the range of valid values. The following query failed: GetUserProfileByName (User: 0#.w|DOMAIN\USER, Form Name: Template012345, IP: , Connection Target: , Request: http://link_to_my_site/AllItems.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:Template012345:-dataFormSolution Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.  Server was unable to process request. ---> Specified argument was out of the range of valid values.  Parameter name: lcid The remote server returned an error: (500) Internal Server Error.)

    In this environment, SharePoint sites were accessible in French and in English. We only had this error for English users. To resolve this issue, we simply add the English language to the Working Language setting of the Managed Metadata Service Application.

    • 15/8/2017

    [SHAREPOINT 2010 - INFOPATH] Erreur Data adapter failed during OnLoad: The remote server returned an error: (500) Internal Server Error

    Hier, lors d'une migration de domaine d'un SharePoint 2010, nous nous sommes retrouvés devant une erreur indiquant qu'il était impossible de se connecter au WebService lors de la création ou la lecture d'un formulaire InfoPath. Les log que nous avions dans l'ULS étaient les suivants :

    Data adapter failed during OnLoad: The remote server returned an error: (500) Internal Server Error.  Server was unable to process request. ---> Specified argument was out of the range of valid values. The following query failed: GetUserProfileByName (User: 0#.w|DOMAIN\USER, Form Name: Template012345, IP: , Connection Target: , Request: http://lien_vers_mon_site/AllItems.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:Template012345:-dataFormSolution Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error.  Server was unable to process request. ---> Specified argument was out of the range of valid values.  Parameter name: lcid The remote server returned an error: (500) Internal Server Error.)

    Dans le cadre de cet environnement, les sites SharePoint étaient accessible en Français et en Anglais et nous avions cette erreur uniquement lorsque des utilisateurs anglophones accédaient aux formulaires. La résolution de ce problème a consisté à ajouter la langue Anglaise dans les Working Language du service de métadonnées gérées. Suite à cela, les utilisateurs anglophones pouvaient correctement ajouter et lire les formulaires InfoPath sans aucunes erreurs.

    • 16/5/2017

    [POWERSHELL] Office 365 For Admin

    Hello tout le monde,

    Je suis en train de développer un (petit qui deviendra gros ^_^) script PowerShell permettant d'effectuer plusieurs tâches d'administration / exploitation en PowerShell. Pour le moment, voici les éléments développés :

    • Exporter tous les utilisateurs vers un fichier CSV
    • Exporter les groupes de distribution & de sécurité vers un fichier CSV (avec ou sans les membres)
    • Exporter tous les groupes Office 365 vers un fichier CSV (avec ou sans les membres)
    • Exporter les licences vers un fichier CSV
    • Exporter les domaines vers un fichier CSV
    • Afficher un utilisateur à l'écran (à partir de son UPN)
    • Afficher les membres d'un groupe à l'écran (à partir de son UPN)
    • Activer / Désactiver la possibilité de créer des groupes Office 365 pour les utilisateurs

    C'est la première version d'un script (composé de plusieurs modules) qui est en cours de développement et pour lequel les fonctionnalités seront ajoutés au fur et à mesure (je fais cela sur mon temps libre ^_^).

    Voici déjà les éléments qui seront présents dans la prochaine itération (je suis actuellement en train de développer ces fonctions) :

    • Exporter la liste des BAL utilisateurs (adresse mail, alias, quotas, ...) vers un fichier CSV
    • Afficher une BAL utilisateur à l'écran
    • Exporter les listes de distribution vers un fichier CSV (avec et sans les membres)
    • Afficher les BAL membres d'une liste de distribution à l'écran
    • Exporter les BAL partagées vers un fichiers CSV (avec et sans les appartenances)
    • Afficher les appartenances d'une BAL partagée
    • Désactiver / Activer la fonctionnalité boîte aux lettres prioritaire et Clutter Mailbox

    Dans le futur, j'y ajouterai :

    • Un module de gestion des utilisateurs (ajout / modification / suppression)
    • Un module de gestion des groupes (ajout / modification / suppression)
    • Un module de gestion des BAL / BAL partragées / listes de distribution (ajout / modification / suppression)
    • Un module de statistique (consommation OneDrive, domaines vers lesquels le plus de mails sont envoyés, les top senders et top receivers, ...)

    N'hésitez pas à me faire des retours sur des fonctionnalités que vous aimeriez bien voir apparaître dans cet outil. Le but étant d'en faire une boîte à outil complète d'administration / exploitation Office 365. N'hésitez également pas à me faire des retours sur les bugs que vous pourriez rencontrer ;) Merci !

    Le lien GitHub : c'est par ici

    1) COMMENT UTILISER LE SCRIPT

    Après avoir récupérer le pack contenant plusieurs dossiers et fichiers, placez-vous dans le dossier les contenant et exécutez le script o365_4_admin.ps1.

    Un menu apparaîtra alors à l'écran. Entrez 2 pour directement quitter le script ou 1 pour vous authentifier sur votre tenant et pouvoir accéder aux fonctionnalités. Suite à cela, une interface vous permettant de renseigner l'identifiant et le mot de passe d'un admin de votre tenant apparaît.

    Une fois authentifié, vous arrivez sur une nouveau menu. Entrez alors 1 afin d'accéder aux fonctionnalités Utilisateurs et Licences ou 99 pour Quitter. C'est à ce niveau que, dans de prochaines itérations, des menus "Exchange Online", "Statistiques", ... apparaîtront.

    Après avoir entré 1, un dernier menu apparaît à l'écran vous permettant d'effectuer l'action désirée. Dans le cas de ce billet de blog, j'ai décidé d'exporter tous les utilisateurs vers un fichier CSV en entrant 1. Le nom du fichier contiendra le nom de votre tenant et sera stocké dans le dossier 00-reports.

    Le lien GitHub : c'est par ici

    Tel qu'indiqué plus haut, n'hésitez pas à me faire des remontées sur ce script :)

    • 15/12/2016

    [PowerShell - DSC] Configurer le nom d'une machine et son IP

    Hello tout le monde,

    Voici mon premier script DSC (tout simple pour commencer :P). Ce dernier s'appuie sur le module xNetworking et xComputerManagement. Il permet de configurer le nom de votre machine ainsi que son IP, DNS, passerelle par défaut & masque sous réseau.

    Le script dispose de  paramètres obligatoires :

    • ComputerName : Le nom que vous voulez assigner à votre ordinateur
    • MofFilePath : Le chemin au niveau duquel vous voulez stocker les fichiers MOF (le script vérifie que le dossier existe et le crée si ce n'est pas le cas)

    Le nom du noeud, le nom de l'interface réseau à configurer, l'IP, le masque de sous-réseau, le type d'IP (v4 ou v6), la passerelle par défaut et les serveurs DNS se configurent au niveau du hastable MyData (à la fin du script).

     

    Le code :

     Configuration ConfigureComputer
    {
    param
    (
    [Parameter(Mandatory=$True)][string]$ComputerName,
    [Parameter(Mandatory=$True)][string]$MofFilePath
    )

    # DSC Resources import

    Import-DscResource -Module xNetworking
    Import-DscResource -module xComputerManagement

    Node $AllNodes.Nodename
    {

    LocalConfigurationManager
    {
    ActionAfterReboot = 'ContinueConfiguration'
    ConfigurationMode = 'ApplyOnly'
    RebootNodeIfNeeded = $true
    }

    File DSCFolder
    {
    Type = 'Directory'
    DestinationPath = $MofFilePath
    Ensure = "Present"
    }

    xComputer NewNameAndWorkgroup
    {
    Name = $ComputerName
    }

    xIPAddress IPAddress
    {
    IPAddress = $Node.IpAddress
    InterfaceAlias = $Node.Interface
    PrefixLength = $Node.IPPrefix
    AddressFamily = $Node.IPAddressFamily
    }

    xDnsServerAddress DnsServer
    {
    InterfaceAlias = $Node.Interface
    AddressFamily = $Node.IPAddressFamily
    Address = $Node.DnsServers
    }

    xDefaultGatewayAddress DefaultGtw
    {
    InterfaceAlias = $Node.Interface
    AddressFamily = $Node.IPAddressFamily
    Address = $Node.Gateway
    }
    }
    }

    $MyData =
    @{
    AllNodes = @(
    @{
    NodeName = 'localhost'
    IpAddress = '192.168.200.10'
    Interface = 'Ethernet'
    IPPrefix = 24
    IPAddressFamily = 'IPV4'
    DnsServers = '8.8.8.8','8.8.4.4'
    Gateway = '192.168.200.254'
    }
    )
    }

     

    Pour démarrer votre configuration : 

    ConfigureComputer -ComputerName "SRV-16-DEMO" -MofFilePath "C:\_DSC" -ConfigurationData $MyData -OutputPath "C:\_DSC"
    Start-DscConfiguration -Wait -Force -Verbose -Path "C:\_DSC\ConfigureComputer"

     

    Si vous voulez télécharger le code c'est par ici :)

    • 15/12/2016

    [PowerShell] Configurer PSGallery comme source de confiance

    Hello tout le monde,

    Je fais pas mal de DSC en ce moment et il faut avouer qu'à chaque fois qu'on installe un module venant de PSGallery, il y a une demande de confirmation un peu ennuyeuse qui indique que nous installons un module venant d'un dépôt qui n'est pas de confiance ...

    Si comme moi vous voulez ajouter PSGallery comme dépôt de confiance, tapez alors la commande suivante : Set-PSRepository -Name PSGallery -InstallationPolicy Trusted.

    Lors de vos prochaines installations de modules en provenance de PSGallery, vous n'aurez plus cette demande de confirmation.

    • 9/12/2016

    [PowerShell] Télécharger les prérequis,CU et packs de langues pour l'installation d'Office Online Server 2016

    [UPDATE - 13/12/2016] : Le script a été mis à jour. Il permet maintenant de récupérer les CU Office Online Server également. Le fichier de réponse XML contient maintenant une section "CumulativeUpdates".

    Je suis en train de déployer du SharePoint 2016 en ce moment avec Office Online Server 2016. Comme pour chacune de mes installations, j'essaye de scripter le plus d'éléments possible. Ainsi, pour télécharger les prérequis et les packs de langues d'OOS, j'ai décidé d'effectuer un script de téléchargement (un comme celui que j'ai fait pour télécharger les prérequis, CU et packs de langues pour SP16). Le script fait les éléments suivants :

    • Le téléchargement des prérequis à installer sur le serveur
    • Le téléchargement du pack de langue fr-fr, es-es, it-it ou en-us
    • Mise en place de paramètres par défaut pour les dossiers de stockage et le pack de langue à télécharger

     

    Etant en Nouvelle-Calédonie, j'effectue toutes mes installations en Anglais en appliquant le pack de langue Français par la suite. Le pack de langue téléchargé par défaut est donc le fr-fr. Le dossier par défaut de téléchargement des éléments est C:\_OOS16SOURCES.

    Le script est composé d'un fichier .ps1 et d'un fichier XML contenant les URL de tous les éléments à télécharger. Si vous exécutez le script .ps1 sans paramètres, il faut que les 2 fichiers soient situés dans le même dossier.

     

    Un exemple d'utilisation du script : .\OOS16_Download-PrerequisitesLP.ps1

     

     

    Pour télécharger le script, c'est sur mon GitHub.

     

    Pour rappel, avant d'installer Office Online Server, il faut installer des prérequis Windows Server. Pour les installer en PowerShell, tapez la commande suivante : 

    Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-Framework-Features,NET-Framework-Core,NET-HTTP-Activation,NET-Non-HTTP-Activ,NET-WCF-HTTP-Activation45,Windows-Identity-Foundation,Server-Media-Foundation

    • 8/12/2016

    [PowerShell] Télécharger les prérequis, CU et packs de langues pour l'installation de SharePoint 2016

    [UPDATE - 10/09/2017] : Le script a été mis à jour. Ajout du CU de Juin, Juillet et Août 2017 dans le fichier XML. Le CU par défaut maintenant téléchargé est celui d'Août 2017. La dernière version d'AutoSPInstaller a également été intégré dans cette mise à jour.

    [UPDATE - 22/05/2017] : Le script a été mis à jour. Ajout du CU d'Avril 2017 et Mai 2017 dans le fichier XML. Le CU par défaut maintenant téléchargé est celui de Mai 2017. La dernière version d'AutoSPInstaller a également été intégré dans cette mise à jour.

    [UPDATE - 23/04/2017] : Le script a été mis à jour. Ajout du CU de Mars 2017 dans le fichier XML. Le CU par défaut maintenant téléchargé est celui de Mars 2017

    Je suis en train de déployer du SharePoint 2016 en ce moment. Comme pour chacune de mes installations, j'essaye de scripter le plus d'éléments possible. Ainsi, pour télécharger les prérequis, les cumulatives updates et les packs de langues, je me suis fortement inspiré de AutoSPSourceBuilder en ne conservant et n'adaptant que les parties nécessaires dans le contexte de mes installations :

    • Uniquement du SharePoint 2016
    • Uniquement les CU SharePoint 2016
    • Uniquement les packs de langue fr-fr, es-es, it-it et en-us
    • Mise en place de paramètres par défaut pour les dossiers de stockage, le CU à télécharger et le pack de langue à télécharger

     

    Etant en Nouvelle-Calédonie, j'effectue toutes mes installations en Anglais en appliquant le pack de langue Français par la suite. Le pack de langue téléchargé par défaut est donc le fr-fr. Le dossier par défaut de téléchargement des éléments est C:\_SP16SOURCES et le CU téléchargé par défaut est celui d'Août 2017 (à date de mise à jour de cet article).

     

    Le script est composé d'un fichier .ps1 et d'un fichier XML contenant les URL de tous les éléments à télécharger. Si vous exécutez le script .ps1 sans paramètres, il faut que les 2 fichiers soient situés dans le même dossier.

     

    Un exemple d'utilisation du script : .\SP16_Download-PrerequisitesCULP.ps1

    Les téléchargements seront stockés dans les dossiers suivants (faisant parti du dossier AutoSPInstaller extrait en tout début de script)

    • SP\2016\Updates
    • SP\2016\LanguagePacks
    • SP\2016\SharePoint\Prerequisites

     

    Un exemple autre exemple d'utilisation du script : .\SP16_Download-PrerequisitesCULP.ps1 -XmlFilePath "SP16DownloadConfiguration.xml" -DestinationFolder "D:\_sp16" -Language "fr-fr" -CumulativeUpdate "November 2016"

     Pour télécharger le script c'est sur mon GitHub.

    Ce script sera mis à jour au fil du temps avec les nouveaux CU, les SP (Service Packs), ...

     

    Stay Tuned !

    • 9/11/2016

    [SharePoint] Modify SharePoint Web Application Name using PowerShell

    Hello,

     

    One of my client needed to rename one of its web application. For the exemple, the name of the web application was "Demi" and he wanted to rename it to "Demo". To modify the name of the web application, use the following commands :

    $webApplication=Get-SPWebApplication | where {$_.Name -eq "Demi"}
    $webApplication.Name="Demo"
    $webApplication.Update()

    To verify that the name has been correctly modify, you can use the following command : Get-SPWebApplication | where {$_.Name -eq "Demo"}

    • 9/11/2016

    [SharePoint] Modifier le nom d'une application web en PowerShell

    Bonjour tout le monde,

     

    Lors d'une de mes dernières prestations, une application web SharePoint avait été déployée avec le mauvais nom. Pour l'exemple, on va dire qu'elle était nommée "Demi" au lieu de "Demo". Voici les commandes PowerShell à taper afin de modifier le nom d'une application web :

    $webApplication=Get-SPWebApplication | where {$_.Name -eq "Demi"}
    $webApplication.Name="Demo"
    $webApplication.Update()

    Une fois ces commandes entrées, nous pouvons vérifier le nom de l'application web en PowerShell avec la commande suivante : Get-SPWebApplication | where {$_.Name -eq "Demo"}

    • 23/10/2016

    [PowerShell] Deploy ADDS on a Server Core

    Hello,

    Today I'm writing a little article on how to deploy ADDS on a server core.

     

    Installation of the role

    If you want to deploy ADDS, you need to enter the following command : Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature

    Deployment of the 1st domain controller in the Forest

    To deploy you first domain controller, you need to create some variables. They will contained some mandatory values needed by the PowerShell command (for more information --> https://technet.microsoft.com/en-us/library/hh974720(v=wps.630).aspx) :


    $CreateDnsDelegation = $false
    $DomainName = "demo.lan"
    $NetbiosName = "DEMO"
    $NTDSPath = "C:\Windows\NTDS"
    $LogPath = "C:\Windows\NTDS"
    $SysvolPath = "C:\Windows\SYSVOL"
    $DomainMode = "WinThreshold"
    $InstallDNS = $true
    $ForestMode = "WinThreshold"
    $NoRebootOnCompletion = $false
    $SafeModeClearPassword = "P@$$w0rd"
    $SafeModeAdministratorPassword = ConvertTo-SecureString $SafeModeClearPassword -AsPlaintext -Force

    The next step is to execute the following command (it will create your domain and promote your server as a domain controller) : 

    $forest = Install-ADDSForest -CreateDnsDelegation:$CreateDnsDelegation `
    -DomainName $DomainName `
    -DatabasePath $NTDSPath `
    -DomainMode $DomainMode `
    -DomainNetbiosName $NetbiosName `
    -ForestMode $ForestMode `
    -InstallDNS:$InstallDNS `
    -LogPath $LogPath `
    -NoRebootOnCompletion:$NoRebootOnCompletion `
    -SysvolPath $SysvolPath `
    -SafeModeAdministratorPassword $SafeModeAdministratorPassword `
    -Force:$true

    • 23/10/2016

    [PowerShell] Déployer le rôle ADDS sur un Server Core

    Bonjour tout le monde,

    Un petit blog post sur comment installer ADDS sur un server Core (déploiement de la fonctionnalité & création du 1er contrôleur de domaine de la forêt).

     

    Déploiement du rôle

    Afin de déployer le rôle Active Directory Domain Services , il suffit de taper la commande suivante : Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature

    Déploiement du 1er contrôleur de domaine

    Afin de pouvoir déployer notre premier contrôleur de domaine de la forêt, il nous faut mettre en place certaines variables indispensables à la bonne exécution de la commande PowerShell (pour plus de détail sur ces dernières --> https://technet.microsoft.com/en-us/library/hh974720(v=wps.630).aspx :


    $CreateDnsDelegation = $false
    $DomainName = "demo.lan"
    $NetbiosName = "DEMO"
    $NTDSPath = "C:\Windows\NTDS"
    $LogPath = "C:\Windows\NTDS"
    $SysvolPath = "C:\Windows\SYSVOL"
    $DomainMode = "WinThreshold"
    $InstallDNS = $true
    $ForestMode = "WinThreshold"
    $NoRebootOnCompletion = $false
    $SafeModeClearPassword = "P@$$w0rd"
    $SafeModeAdministratorPassword = ConvertTo-SecureString $SafeModeClearPassword -AsPlaintext -Force

    Une fois ces variables créées, nous pouvons installer notre premier contrôleur de domaine de la forêt en tapant la commande suivante :

    $forest = Install-ADDSForest -CreateDnsDelegation:$CreateDnsDelegation `
    -DomainName $DomainName `
    -DatabasePath $NTDSPath `
    -DomainMode $DomainMode `
    -DomainNetbiosName $NetbiosName `
    -ForestMode $ForestMode `
    -InstallDNS:$InstallDNS `
    -LogPath $LogPath `
    -NoRebootOnCompletion:$NoRebootOnCompletion `
    -SysvolPath $SysvolPath `
    -SafeModeAdministratorPassword $SafeModeAdministratorPassword `
    -Force:$true

    • 22/10/2016

    [DIVERS] Informations à fournir lors d'une migration de Messagerie On-Prem vers Exchange Online

    Hello tout le monde,

     

    J'ai réalisé pas mal de migrations de messagerie On-Prem (Exchange et principalement non Exchange) vers Office 365 depuis ces 2-3 dernières années et j'ai également répondu à des d'appels d'offres traitant de ce sujet (ou il fallait chiffrer la prestation mais également les licences du produit de migration et les licences Office 365). Voici un petit retour d'expérience sur quelques informations qu'il faut fournir (notamment dans l'appel d'offres) et qui sont bien souvent manquantes (pour une partie d'entre elles) :

    • Le logiciel de messagerie utilisé : Il est important de fournir le logiciel de messagerie utilisé ainsi que sa version.
    • Le type de connexion Internet et le débit : En Nouvelle-Calédonie, nous avons un Internet qui n'est pas aussi rapide qu'en Europe ou en Amérique de Nord (surtout en Upload, on est souvent limité à 1Mo si on est abonné ADSL. Il est possible d'avoir plus si on dispose d'une LS ou du RFIP). Il est donc important de fournir cette information nous permettant d'estimer les temps de migration.
    • Le nombre de BAL : Bien souvent le nombre d'utilisateurs et fournis mais pas le nombre de BAL (boîtes aux lettres). Il est important de connaître le nombre de BAL individuelles et partagées exactes qu'il faudra migrer (les BAL partagées sont souvent oubliées).
    • Utilisation ou non de liste de distribution et si oui combien : Cela nous permet de savoir s'il faudra en recréer et combien il faudra en recréer (cette tâche étant normalement scriptée à l'aide d'un fichier d'entrée contenant les listes à créer ainsi que leurs membres).
    • Utilisation des ressources (salles de réunions, véhicules, ...) et si oui combien : Ceci est souvent utile pour les licences du produit de migration (pour les solutions de messagerie On-Prem non Microsoft type Lotus par exemple que l'on migre vers Office 365). En effet, les produits de migration imposent souvent l'achat d'une licence pour chaque ressource que nous migrons (je parle pour les produits de migration que j'ai pu utiliser, je ne les connais bien entendu pas tous).
    • La volumétrie globale des BAL actives : Ceci permettra d'estimer le temps global de migration (en fonction du débit mais aussi des limitations Microsoft --> https://technet.microsoft.com/en-us/library/dn592150(v=exchg.150).aspx).
    • La volumétrie moyenne d'une BAL
    • Est-ce qu'il y a des archives à migrer : Les archives sont souvents oubliés dans les appels d'offres. Il est important d'indiquer s'il y a des archives, si celles-ci doivent être migrées. Il est également important d'indiquer si elles sont sur le serveur ou sur les postes utilisateurs.
    • S'il y a des archives, la volumétrie globale des archives : Ceci permettra d'estimer le temps global de migration (en fonction du débit mais aussi des limitations Microsoft --> https://technet.microsoft.com/en-us/library/dn592150(v=exchg.150).aspx).
    • S'il y a des archives et que ce paramètre est connu, la volumétrie moyenne d'une archive
    • Quelle est la stratégie de reprise des données : Est-ce que l'intégralité des mails doivent être migrés pour chaque BAL ou ne migrons-nous que les 6 derniers mois ou la dernière année ou les 2 dernières années ? Que faisons-nous des archives (les mettre sur les postes uniquement ou les envoyer dans l'archive online) ?
    • Y a t'il des dossiers publics (ou technologie équivalente sur d'autre technologie non Microsoft) : S'il y en a préciser la volumétrie.
    • Quelle stratégie de migration voulez-vous utiliser : Si vous savez déjà comment vous voulez migrer, indiquez le (migration "big bang", cohabitation, ...). En cas de cohabitation, indiquez si vous voulez que les 2 systèmes se "voient" (est-ce que les personnes de "l'ancien système" doivent pouvoir voir les disponibilités du calendrier de ceux présents sur le nouveau système, ...).
    • Faut-il synchroniser l'Active Directory local de l'entreprise avec Office 365 : Ceci est une information importante permettant de connaître la stratégie de gestion des utilisateurs et qui influt sur l'architecture à mettre en place (mise en place d'un serveur supplémentaire pour la synchronisation). Il est faut également préciser si la synchronisation des mots de passe doit être mise en place ou non.
    • Est-ce qu'il faut mettre en place du SSO : Le SSO permettra aux utilisateurs de ne pas avoir à retaper leur mot de passe lorsqu'ils sont authentifiés sur leur session Windows de domaine. Ce paramètre va influer sur l'architecture à mettre en place (plusieurs serveurs supplémentaires devront être configurés).
    • Y a t'il des équipements ou logiciels qui utilisent le SMTP On-Premise pour envoyer des mails : Les copieurs fournissent la possibilité de "Scan To Mail" et beaucoup d'applications envoient automatiquement des emails. Si c'est le cas, il faudra mettre en place et configurer un relais SMTP.

     

    Le fait de connaître les volumétries nous permet d'estimer les temps d'upload des BAL actives et des archives dans le cloud et la taille moyenne d'une BAL active / archive nous permttra de réaliser un planning de migration en fonction de la volumétrie migrable par journée de migration (souvent nuit et week-end de migration pour ne pas impacter les utilisateurs en journées).

    Bien entendu, pas mal de ces questions peuvent être discutées avec le prestataire afin qu'il vous fournisse la solution la plus adaptée à votre besoin et votre contexte et qu'il vous conseille si vos choix ne sont pas arrêtés (sur la reprise de données ou la migration des archives par exemple).

     

    N'hésitez pas à commenter ou donner vos retours d'expérience :)

    • 19/10/2016

    [PowerShell] Outil de déploiement ADDS

    Bonjour tout le monde,

     

    Comme je monte pas mal d'AD en ce moment (pour des labs ou des clients), je me suis fait des petits scripts PowerShell pour me faciliter la vie. Récemment, j'y ai même ajouté un interface graphique afin de directement modifier les valeurs de mes variables par le biais de cette interface.

    Tout a été intégralement codé en PowerShell avec PowerShell Studio.

     

    Cet outil est composé de deux onglets. Le premier permet de configurer le nom du serveur, son IP, son préfixe réseau, sa gateway et son ou ses serveurs DNS (séparés par des virgules). Une fois toutes les informations renseignées, vous pourrez cliquer sur le bouton Configure Server.

     

     

    Le second onglet permet de déployer la fonctionnalité ADDS ainsi qu'une nouvelle forêt. Vous pouvez alors renseigner le nom de domaine, le nom NETBIOS, le niveau fonctionnel du domaine (WIN2003 à WIN2016), de la forêt (WIN2003 à 2016) et votre Safemode Password. Une fois toutes les informations renseignées, vous pourrez cliquer sur le bouton Deploy ADDS.

     

    Vous pouvez télécharger le code source PowerShell ainsi que le projet PowerShell Studio ici --> http://bit.ly/2eT4CIf 

    Vous trouverez également joint à ce poste, une archive contenant l'exécutable.

     

    Dans le futur, d'autres onglets seront ajoutés pour, par exemple, ajouter un contrôleur de domaine à un domaine existant, déplacer les rôles, ...

    N'hésitez pas à me faire des retours sur votre utilisation, les éventuels bugs ou autre :)

     

    Attention : Cette application est fournie gratuitement sans aucune garantie ou sans aucun support.

    • 23/8/2016

    [Pester] Install Pester on Windows 10

    It's been a while since I wanted to test Pester and I finally find the time to test it. Pester is a BDD (Behaviour-Driven Development) based test runner for PowerShell (https://github.com/pester/Pester/wiki/Pester). We want to use this kind of tool when we want to verify that the result of a PowerShell function is really what we are waiting for. It is useful when we are modifying code we want to assure that the result is still the same.

    To install Pester, enter the following command : Install-Module -Name Pester

    To verify Pester has been correctly installed : Get-Module -ListAvailable -Name Pester

    To import Pester : Import-Module -Name Pester

    In my next article, I will explain a simple case study !

    • 23/8/2016

    [Pester] Installer Pester sur Windows 10

    Cela fait un moment que je me dis qu'il va falloir que je me mette à utiliser Pester. Pester est un framework de test unitaire pour PowerShell. Il va donc nous permettre de valider que le résultat d'une fonction est bien ce à quoi nous nous attendons. C'est très utile notamment lorsque nous modifions nos scripts ;)

    Pour installer Pester sur Windows 10, entrer la commande suivante : Install-Module -Name Pester

    Pour vérifier que le module est bien installé : Get-Module -ListAvailable -Name Pester

    Pour importer Pester : Import-Module -Name Pester

    Dans un prochain article, je détaillerai un exemple simple d'utilisation de Pester !

    • 21/8/2016

    [AZURE AUTOMATION] Stopper les VMs Azure tous les soirs

    Hello tout le monde,

    Aujourd'hui j'ai décidé de faire un petit post sur Azure Automation. Comme beaucoup de personnes, il m'est (trop) souvent arrivé d'oublier d'éteindre mes VMs Azure à la fin de test et de (trop vite) me retrouver avec tout mon crédit MSDN consommé ...

    J'ai donc mis en place dernièrement un script PowerShell qui éteint les VMs Azure démarrées tous les soirs. Quoi de mieux pour cela qu'Azure Automation.

    1/ CRÉER UN COMPTE AUTOMATION

    Si ce n'est pas déjà fait, créez-vous un compte Azure Automation.

    2/ AJOUTER UN NOUVEAU RUNBOOK

    Une fois votre compte créé, il vous faut ajouter un nouveau runbook. Vous avez normalement 4 runbooks par défaut qui ont été déployés lorsque vous avez créé votre compte Azure Automation. Vous pouvez les supprimer.

    Créez un nouveau Runbook de type PowerShell.

    Utilisez le script Stop-AureVM sur mon Github pour ce runbook. Ce dernier permet d'arrêter toutes les VMs encore en statut "Running". Une fois ceci effectué, cliquez sur "Enregistrer" puis sur "Publier".

     

    3/ TESTER VOTRE SCRIPT

    Maintenant que vous avez ajouté votre script, exécutez-le afin de valider qu'il stoppe bien toutes vos VMs (il faut bien entendu que vous ayez des VMs d'allumées). Pour cela, cliquez sur le bouton "Démarrer".

    La sortie de l'exécution doit vous afficher la liste de toutes les VMs que le script a éteint.

    3/ PLANIFIER L'EXÉCUTION

    Il nous faut maintenant ajouter une planification à notre runbook afin que ce dernier s'exécute automatiquement tous les soirs (à 23h00 dans mon cas).

    Pour ce faire, cliquez sur Planifications puis sur Ajouter une planification puis sur Associer une planification à votre runbook.

    Au niveau de votre planification, donnez-lui un nom, choisissez une heure et une périodicité (23h00 tous les jours dans mon cas).

    Toutes vos VMs s'arrêteront automatiquement tous les soirs à 23h si vous avez oublié de les éteindre.

    • 14/7/2016

    [OUTIL] Réinitialiser un compte AD

    Bonjour tout le monde,

    Voici un petit post sur un outil que j'ai créé qui permet d'effectuer les tâches suivantes sur un compte AD :

    • Réinitialiser le mot de passe d'un compte AD
    • Demander à l'utilisateur de changer son mot de passe à la prochaine connexion
    • Activer / Désactiver un compte AD
    • Déverrouiller un compte AD
    • Assigner un date d'expiration à un compte AD

    Afin de pouvoir exécuter cet outil, il faut être connecté sur un PC de domaine avec un compte AD ayant le droit d'effectuer toutes ces actions. Ce PC n'a pas besoin d'être un contrôleur de domaine. L'application récupérera automatiquement le module AD depuis un DC et le chargera sur votre ordinateur. Afin de pouvoir effectuer cela, il faut que le PSRemoting soit activé. Ce module étant chargé avant l'ouverture de l'application et cette action pouvant prendre quelques secondes, il est possible que l'application mette 5-10s à s'ouvrir.

    Une fois ceci effectué, entrez le nom ou le prénom de l'utilisateur (ou les 2 :P) dans la zone "Utilisateur" puis cliquez  sur "Valider" afin de rechercher votre utilisateur. Si plusieurs utilisateurs ayant le même prénom ou nom existent, la drop down list sera remplie avec tous les comptes AD.

    Après avoir sélectionné votre compte, vous pouvez choisir l'action (ou les actions) que vous voulez effectuer.

    N'hésitez pas à me remonter d'éventuelles améliorations / bugs ou autre concernant cet outil :) Je le joins à la fin de ce post sous la forme d'un fichier zip.

    Cet outil a été réalisé en PowerShell avec PowerShell Studio !

    Attention : Cette application est fournie gratuitement sans aucune garantie ou sans aucun support.

    • 12/7/2016

    [PowerShell] Récupérer la liste des utilisateurs n'ayant pas de licences Office 365

     J'ai récemment réalisé un script PowerShell permettant d'exporter vers un fichier CSV la liste de tous les utilisateurs Office 365 n'ayant pas de licences.

    Les paramètres obligatoires :

    • $CSVFilePath : Paramètre non obligatoire au niveau duquel vous devez indiquer le chemin du fichier CSV dans lequel sera stocké la liste de tous les utilisateurs n'ayant pas de licences. Par défaut, ce document sera sauvegardé sur le bureau si vous ne spécifiez aucune valeur.
    • $O365AdminLogin : Paramètre obligatoire au niveau duquel vous devez renseigner le login d'un utilisateur administrateur Office 365.
    • $O365AdminPassword : Paramètre obligatoire au niveau duquel vous devez renseigner le mot de passe de votre utilisateur administrateur Office 365.

    Un exemple d'utilisation : .\O365_Get-UnlicensedUsers.ps1 -CSVFilePath "C:\_\unlicensed_users.csv" -O365AdminLogin "admin@domain.com" -O365AdminPassword "XXXXYYYY"

     Le résultat du fichier CSV :

    Pour télécharger le script, c'est par ici : https://github.com/sschorgen/PowerShell/blob/master/O365_Get-UnlicensedUsers/O365_Get-UnlicensedUsers.ps1

    • 15/6/2016

    [PowerShell] Déléguer le contrôle total sur une BAL Office 365

     Lorsque vous voulez donner le droit "Full Control" à votre administrateur (ou un autre utilisateur) sur une boîte aux lettres Exchange Online (ou Exchange), vous pouvez soit passer par l'interface web existante, soit utiliser PowerShell (ce que je préfère lorsqu'il y a 200 compte à configurer ;) ).

    Voici la commande permettant de déléguer le contrôle total d'une boîte à un utilisateur : Add-MailboxPermission -Identity "utilisateur@domaine.com" -User "utilisateur_a_qui_vous_donnez_le_droit@domaine.com" -AccessRights FullAccess -Confirm:$False

    Dans cette commande :

    • Utilisateur@domaine.com : Correspond à la boîte sur laquelle vous allez donner la délégation
    • Utilisateur_a_qui_vous_donnez_le_droit@domaine.com : Correspond au compte à qui vous voulez donner le droit "Full Control"