Merci à vous de suivre le flux Rss de www.sospc.name. ;o)<
Jeff77 continue pour notre plus grand plaisir d'améliorer son outil. Comme expliqué les mois précédents, vous allez pouvoir accéder non pas à la dernière, mais l'avant dernière version de son couteau suisse. Ce sera en l'occurrence la V23.0.0.8. Bonne découverte. 😉 *** Principales nouveautés V23 Ajout menu DATES IMPORTANTES (Depuis le SOMMAIRE / MATERIEL) Améliorations […]
In this edition of our series on the "Top 5 Best Practices for Exchange Online Domain Transfers," we delve deeper into the importance of validating your plan prior to implementation. Implementing a well-tested and practiced process will help prevent mistakes and encountering unknowns during the migration. Join us as we explore the key considerations for a successful validation phase.
Il faut comprendre que la surveillance n'est pas une finalité, mais un cheminement. Les organisations étant de plus en plus nombreuses à migrer dans le cloud, elles doivent apprendre à se protéger et à détecter où elles se situent et la maturité de leurs équipes qui gèrent des projets dans le cloud.
Merci à vous de suivre le flux Rss de www.sospc.name. ;o)<
Jeff77 continue d'améliorer son outil. Comme expliqué le mois dernier, vous allez pouvoir accéder non pas à la dernière, mais l'avant dernière version de son couteau suisse. Ce sera en l'occurrence la V22.0.0.5. Bonne découverte. 😉 *** Principales nouveautés V22 Batterie : Détection automatique de l'état d'usure de la batterie des ordinateurs portables. Réglage […]
Merci à vous de suivre le flux Rss de www.sospc.name. ;o)<
Jeff77 continue pour notre plus grand plaisir de faire évoluer son outil. Certains d'entre vous m'ont écrit le mois dernier en s'étonnant de ne pas voir d'articles sur la version 21 qui venait d'être publiée. Je profite de cette publication pour expliquer ma nouvelle démarche. Jusqu'à la version 20 je publiais un article à chaque […]
Récemment, j’ai fait l’acquisition d’un nouveau NAS : DS923+. Il vient remplacer un DS918+ qui nous a suivis pendant de nombreuses années. Pour ne pas perdre les données et paramètres, j’ai éteint l’ancien NAS, retiré les disques un à un… puis j’ai remis ces derniers dans le même ordre dans le nouveau NAS. Après avoir appuyé sur le bouton Marche/Arrêt : tout ne s’est pas passé comme prévu. Synology et migration de disques Ce n’est pas le premier changement de […]
Microsoft Azure knows SQL Server best and will support your cloud migration at no cost for qualifying scenarios.
The SQL Server platform has been successfully driving transformative business results with Microsoft customers across industries for over 25 years, enabling breakthrough innovation through unique capabilities like industry-leading performance1 and security built-in.
Microsoft's continuous investments in SQL Server enable more flexibility with options for companies looking to simply save on costs, or to really transform their current SQL Serverbased applications and data estate.
These options include:
Azure SQL Managed Instance, a fully managed cloud database that is compatible with SQL Server back to version 2008.
A serverless compute version that stops, starts, and scales with your workloads.
Elastic pools for managing groups of databases with ease.
Hyperscale, the flexible, high-performance service tier that scales to meet demandall unique to Azure.
Reasons for choosing Azure over other clouds for your SQL Server applications go beyond having access to more options to meet your business and technical needs. SQL Server running in Azure also enables higher savings than AWS with faster performance1, lower downtime2, and AI-based, automatic tuning that continuously maintains peak database performance. Azure SQL is based on the SQL Server database platform, the least vulnerable commercial database in the NIST National Vulnerability Database for over 10 years3.
With Microsoft you can also decide where you want to run your SQL Server databases in your own datacenter, the cloud of your choice, or hybrid and multicloud deployments with Azure Arcenabled SQL Managed Instance and the recently launched SQL Server 2022.
SQL Server 2022
The most Azure-enabled release yet, with continued performance, security, and availability innovation.
If you're considering moving to the cloud, besides getting the most out of a cloud-based SQL Server, you can take the first step with Azure free of charge. I'm pleased to share that the newMicrosoft SQL + Apps Migration Factoryinitiative can support your low-friction migrations of SQL Server and Windows Serverbased applications at no cost.
The Microsoft SQL + Apps Migration Factory is a delivery model offered through the Unified/Customer Success resources that gathers skilled professionals, comprehensive processes, and tools to help you plan, execute, and migrate qualifying SQL Server workloads and associated application virtual machines (VMs) to Azure with near-zero code changes. In other words, it blends the technical components of cloud migration with the business and human componentsso critical to helping you achieve your goals.
With this offer, you can get specialized assistance to help choose the migration approach that suits your business, such as moving a single workload or having a migration in phases, as well as guided savings and application assessments. All with the main goal of having a seamless and efficient workload migration without business disruption. Once your environment is migrated, our team can also help ensure the SQL Server workload is properly secured and performs adequately.
Hundreds of customers have already signed up to leverage this Customer Success Factory delivery model to accelerate migrations of known low-friction scenarios that do not require refactoring. Typical use cases favored by customers have included out-of-support SQL Server and Windows Servers, dev-test environments, disaster recovery (DR) environments, and applications with a compelling business need to migrate to the cloud in the near term that do not require refactoring or rewriting. This approach also minimizes the risk of business disruption as the migration journey is jumpstarted with these low-friction scenarios and advancing your digital transformation priorities in a phased manner. We like to think of this approach as eating your cake one slice at a time and we can support slices as small or as big as you need. You can even come back for seconds and thirds at any time to advance your migration and modernization journey in an iterative and controlled manner.
So, if your SQL Server estate, including associated Windows Serverbased apps, has these or other scenarios that are ready to migrate in the near term without refactoring to optimized Azure SQL and Azure VM destinations, talk to your Microsoft account team about the Factory delivery model or apply now to get started.
4Subject to the limitations described in the full SQL + Apps Migration Factory program specifications here, and provided that the SQL Server workloads are low complexity with no code changes, Microsoft agrees to assess and migrate SQL Server databases and SQL Server-associated applications from your datacenter or AWS EC2 to Azure at no cost to customer. Migrations must be completed by June 30, 2023.
Vous avez GSuite, et vous devez migrer vers Microsoft365… Comment faire ? Quel(s) outil(s) ?
D’un côté GSuite avec des utilisateurs, des drives, des calendriers etc …
De l’autre Microsoft365 aka M365
Entrons dans le vif du sujet,
Microsoft propose une solution pour migrer les drive et la messagerie (incluant, contact, calendrier) avec quelques limitations indiquées sur le site de l’éditeur.
Voici le step by step pour les mails :
Depuis la console Admin 365 direction Exchange Online (une fois l’ensemble des comptes utilisateurs créé au préalable of course)
Suivez les indications à l’écran en sélectionnant bien GSuite
Vous pouvez utilisez la création automatique du projet de migration via Microsoft, en vous authentifiant avec votre login Admin Google.
Cela va initié un certain nombre de chose, dont une liste d’API à autoriser. Evidemment … pas complète … et vous télécharger un fichier JSON à conserver pour la création du point de terminaison dans 365.
Une fois que tout cela est fait, ajouter un CSV de cette forme
Choisissez les items à migrer, par date, type etc …
Enfin sélectionner le EndPoint, ou bien créé le et valider le avec le fichier JSON téléchargé.
La plupart des erreurs à ce niveau sont un mélange entre les noms de projet de migration google, les apis et les Json qui ne correspondent pas au batch de migration créé … bref ça fait spaghetti …
Une fois que tout cela est correct, y’a plus qu’a appuyer sur le bouton migration et attendre (pour faire simple) enfin migration … synchronisation plus exactement. Une fois la synchronisation terminée, il vous faudra compléter cette synchronisation pour mettre fin à la “migration” de la boite Gmail. Puis une fois que tout le monde à migrer opérer les redirections MX de Google vers Microsoft
N’oubliez pas que votre stratégie de migration est primordiale, et la communication avec les utilisateurs aussi, c’est bien de les faire déménager mais peut-être que certaines actions seront encore à réaliser de leur côté.
Pour la partie GDrive le principe est similaire et encore plus simple
Direction l’administration de SharePoint Online puis Migration et sélectionner Google
Vous arrivez sur une page similaire pour connecter Google à Microsoft (ici c’est du box mais c’est pareil pour les autres) rien de trop compliquer à faire ici authentifiez vous avec le compte Admin Google et Microsoft fait le reste (correctement)
Vous avez deux sections (Scan et Migration)
Le scan lui fonctionne tout seul :
Une fois lancé vous avez une liste de tout les drives partagés comme personnels et vous pouvez filtrer.
Une fois le(s) drive(s) choisi(s) copier les vers Migrations puis (vous vous souvenez du deuxième choix – celui à côté de Scan >> cliquer dessus)
Une fois sur migration, vous avez la possibilité d’exporter la liste de migration via CSV pour définir une cible (OneDrive, SharePoint, Teams) ou manuellement si vous voulez, mais ca peut être long …
Pour tout exporter, il ne faut sélectionner aucuns éléments (oui oui je sais)
Un élément intéressant est le mapping des identités qui lui ce fait tout seul (si vos identités sont correctes prenom.nom@domaine.com) mais aussi la possibilité d’ajouter des Tags (qui correspondent en générale a votre stratégie de migration (par pays par exemple))
Je reviens une demie seconde sur le mapping, si vos identités ne changent pas en termes de nomenclature, utiliser un mapping de domaine c’est plus simple, plus rapide, plus propre, et source de moins d’erreurs
Une fois le fichier envoyé, sélectionner les Drive a migrer ou via les Tags puis sélectionner “Migrate”
Cela fonctionne pareil pour les Drive Personnel, mais qui ont plus tendance à aller dans OneDrive (avec un fichier Excel et quelques formules c’est assez simple)
Ah oui …. une fois le batch lancé, vous ne pouvez pas re modifier le chemin d’accès de destination.
Et voilà !
En soit ce n’est pas bien compliqué une fois sorti des noms de domaine, DNS, etc … Pensez a arrêter le drive Google une fois migré et surtout prévenir les utilisateurs de ne plus utiliser Gmail une fois migrer, ou bien verrouiller les accès aux users qui ont migré.
Les outils de migration de marché vous apporterons plus de flexibilité ainsi qu’un pilotage beaucoup plus précis. Mais avec de la rigueur et un suivi impeccable vous avez de quoi vous en sortir
In July 2022, Microsoft announced that they would stop the automatic provisioning of a wiki tab for new Teams channels. On 11 January 2023, Microsoft followed up with news of the retirement of the Teams wiki app in February 2023 (MC496248). OneNote is the replacement app and Microsoft plans to deliver an app to migrate wiki content to OneNote notebooks stored in SharePoint Online. The wiki content is already in SharePoint Online, so the migration moves whatever’s in the wiki to the default shared OneNote notebook. Once the migration finishes, Teams locks the wiki, and users work with OneNote from that point.
The migration app is due to roll out in mid-February. Eventually, Microsoft plans to remove the wiki app and tab from Teams.
The Need to Find Wikis
The reaction to Microsoft’s announcement has been positive. OneNote is a more functional application, and the Teams wiki never found much favor with customers. Although the change is good, some up-front work is necessary to prepare for the transition. One obvious question is what Teams channels have a wiki. The natural follow-up is to ask if any wikis contain something worth migrating.
Assessing the worth and importance of wiki content is not something that’s easy to automate. You could scan the SharePoint Online site and examine the date of the latest update for the wiki files to conclude if the wiki is active. Measuring what might be in the wiki is another matter. Beauty is very much in the eye of the beholder and what appears to be someone else’s rubbish might be critically important to them. But we can discover which Teams channels have wiki tabs and report that data to use as a guide to wiki migration.
Several years ago, I wrote a PowerShell script that uses Graph API requests to report the tabs and applications used by Teams channels. I took the code and amended it to generate a wiki report and replaced the Graph API requests with cmdlets from the Microsoft Graph PowerShell SDK to allow the script to run without needing to create a registered Azure AD app. Of course, if you want to, you can amend the original code and run it with a registered app. That’s an exercise for the reader.
Graph Documentation Improvements
Apart from not needing a registered app, using the Microsoft Graph PowerShell SDK illustrates how broadly the SDK extends. Microsoft is gradually updating Graph documentation to include PowerShell examples that feature SDK cmdlets. For instance, the Get channel API returns details of a channel in a team. Its examples include how to use the Get-MgTeamChannel cmdlet.
Another piece of essential information found in the Graph documentation is the application permission needed to run a request (or its matching cmdlet), like the ChannelSettings.Read.All permission needed to fetch channel settings. See this article for more information about figuring out Graph permissions.
Generating a Teams Channels with Wiki Report
Getting back to finding Teams wikis, the steps are simple:
Find all teams with the Get-MgTeam cmdlet. It’s critical to use the Select-MgProfile cmdlet to attach to the Graph beta endpoint because Get-MgTeam doesn’t support fetching all teams with the V1.0 endpoint.
For each team, find all channels with the Get-MgTeamChannel cmdlet.
For each channel, examine the tabs with the Get-TeamChannelTab cmdlet and collect information.
Examine each tab. If it’s a wiki tab, fetch details of the tab using some data exposed by the Get Tab Graph API (using the Get-MgTeamChannelTab cmdlet). For most wiki tabs, this returns a configuration property that holds a ‘hasContent’ value if anyone has edited the wiki. Some older wiki tabs don’t return a configuration property.
For wiki tabs with content, find the team owners because they are the best people to check the wiki to decide if it should be migrated to OneNote.
Generate the report of Teams wikis for checking. Figure 1 shows the output from the PowerShell list, which the code also saves to a CSV file. If you want something nicer, consider exporting to an Excel worksheet.
The script I used to create the report shown in Figure 1 is available from GitHub. Use the latest version from 26 January 2023 or later.
Figure 1: Reporting Teams channels with a wiki tab
The script is pure PowerShell so it’s easy to change to meet individual requirements. Have fun tracking down those pesky Wikis!
Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.
Aujourd’hui nous allons voir comment migrer une machine virtuelle Windows Server 2012 R2 depuis un Hyper-V (version 2019) vers un Proxmox en version 6.4.4.
I) Le lab et rapides explications~
Rien de très sorcier ici :
PVE 6.4.4 : 192.168.0.100/24 ;
Hyper-V 2019 : 192.168.0.110/24 ;
VM ActiveDirectorysous WS2012 R2: 192.168.0.150/24 ;
Côté AD, je n’ai créé qu’un ou deux utilisateurs, ainsi que deux OUs. L’important est vraiment de s’assurer qu’après la migration les users soient toujours là, mais en pratique aucun soucis. D’ailleurs, nous verrons une commande pour vérifier si le disque virtuel ne présente pas de corruptions (toujours utile à savoir, surtout qu’en production ce ne sera pas de simples disques de 30Go que vous allez migrer, mais des disques faisant plusieurs Téraoctets…).
II) Copie du disque VM vers le nœud Proxmox
Bien, une fois votre VM installée et votre AD un peu peuplé, on peut stopper la machine virtuelle, puis copier son disque.
Deux OUs, et deux users, classique.
Pour copier le disque il n’y a pas de manipulations particulières, simplement copier le .vhdx, car même si la documentation de Proxmox ne parle que de .vhd, ce dernier supporte tout à fait les .vhdx. Aucun soucis donc.
Sachez cependant qu’une applet Powershell existe pour convertir un .vhdx en .vhd, si vraiment le besoin s’en fait sentir.
Si vous devez copier un disque de gros volume, le plus simple est encore de le copier sur un volume partagé, avec une liaison Gigabit voir 10-Gigabit. Sinon, dans le cadre de ce lab, un simple scp suffit :
Ici je copie directement le disque depuis mon hôte Hyper-V, à destination de mon nœud Proxmox, dans le dossier root.
Si vous vous posez la question « quid si la VM possède plusieurs disques ?« , et bien en théorie pas de soucis, la marche à suivre sera sensiblement la même, mais ne l’ayant pas encore pleinement testé à l’heure où j’écris ces lignes, je ne peux vous le garantir. Sûrement un prochain article !
III) Re-création de la VM côté Proxmox
La première étape est donc de re-créer une VM, en essayant dans la mesure du possible de reprendre les mêmes configurations hardware (si votre VM avait 4Go de ram, ne pas lui en mettre 2, ou même 8, en tout cas au départ, etc.)
On créer donc notre VM, de sorte que :
L’OS Invité choisi soit de type Windows (ou Linux si votre VM était une Linux, cela tombe sous le sens) ;
Pas encore d’image ISO à attacher ;
Au niveau de la carte graphique, j’ai lu que SPICE était assez souvent utilisé, mais ici je garderai le standard sous peine d’avoir un curseur qui n’en fait qu’a sa tête… ;
Concernant le Contrôleur SCSI, bien choisir VirtIO SCSI ;
Concernant le BIOS, opter plutôt pour l’OVMF/UEFI ;
Concernant le disque, ce n’est pas important car une fois notre VM créée celui-ci sera supprimée pour être remplacée par notre .vhdx fraîchement copié ;
Concernant le driver réseau, privilégiez Virtio(paravirtualisé) ;
Terminer, sans démarrer d’ores et déjà la VM ;
Je ne l’ai pas dit plus haut pour ne pas vous embrouiller, mais dans l’état, si l’on démarre notre VM, Windows ne détectera pas le disque ni la carte réseau. La raison est que nativement, les drivers VirtIO ne sont pas inclus dans Windows. Nous avons donc deux choix :
Installer les drivers VirtIO sur la VM avant de copier son disque ;
Démarrer tout de même la VM, puis installer les drivers par la suite ;
Je n’ai pas encore testé la première option, nous partirons donc sur la seconde. Mais avant de vouloir démarrer le tout et installer tel ou tel driver, nous devons rattacher notre ancien disque !
Bien, la première étape est de supprimer le disque de notre VM actuelle :
On le détache, puis on le supprime.
Une fois fait, on se connecte en CLI sur notre nœud Proxmox pour rattacher notre disque « Hyper-V » sur notre nouvelle VM :
qm importdisk 100 /root/srv-ad-01.vhdx local-lvm
On utilise donc l’utilitaire qemu pour importer notre disque sur la VM ayant l’ID 100, à adapter selon votre VM donc. Ensuite, on renseigne le chemin vers ce disque, et en dernier lieu on indique le datastore sur lequel il va être stocké. Ici il s’agit du datastore de base, local-lvm. Mais si vous utilisiez Ceph par exemple, cela aurait pu être rbd-datastore-24, ou que sais-je.
On patiente pendant l’import (qui peut parfois durer très longtemps !), et une fois fait, nous pourrons le rattacher à notre VM.
Au passage, voici la commande pour vérifier l’intégrité d’un disque, toujours pratique à effectuer avant de l’importer sur notre datastore :
qemu-img check srv-ad-01.vhdx
Extrêmement simple à réaliser, mais toujours important !
Bien, retournons donc sur les paramètres de notre machine virtuelle :
On clique donc sur Éditer, puis on choisi bien le contrôleur VirtIO SCSI. On peut éventuellement activer l’émulation SSD, le caching, ou autre.
On touche désormais presque à la fin !
IV) Démarrage de la VM et installation des drivers OpenSource VirtIO
Comme dit précédemment, il vous faudra des drivers à installer, tout dû moins pour le disque, et éventuellement pour la carte réseau si vous avez aussi choisi VirtIO. Rien de compliqué je vous rassure !
On télécharge l’ISO contenant les différents drivers VirtIO ici : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
*Pour ma part, j’ai choisi la version 215-2, car la dernière en date ne fonctionnait pas.
Une fois l’ISO téléchargé, on l’upload sur notre Proxmox, et on le rattache à notre machine virtuelle. On peut enfin modifier l’ordre de boot, et nous pourrons démarrer !
Ici j’ai désactivé le boot via PXE mais pas via CD, car nous voulons que notre VM boot sur notre disque, mais si on ne sélectionne pas notre lecteur CD, l’ISO ne montera pas au boot…
Au démarrage, votre Windows plantera. Puis encore une fois, et même éventuellement une troisième fois.
C’est normal ! Rappelez-vous, il n’a pas encore les drivers adéquats… cela nous permettra d’afficher le mode Rescue de Windows, et d’accéder à une invite de commandes :
Au passage, il se peut que votre curseur n’en fasse qu’à sa tête… cela peut venir du fameux pilote SPICE choisi pour la carte graphique, si vous n’avez pas choisi le standard.
Bien, on va donc maintenant installer le driver concernant notre disque SCSI VirtIO :
drvload D:\vioscsi\2k12R2\amd64\vioscsi.inf
A noter que la commande sera identique peut importe la version de Windows utilisée :
Et le tour est joué ! Ni plus, ni moins. On peut clôturer ce terminal et poursuivre le boot de manière normale :
Et voilà, votre VM Windows Server 2012 R2 migrée depuis votre Hyper-V s’allume sous vos yeux !
Cependant, comme pour le disque, il n’y a pas encore le driver correspondant à la carte réseau. Mais étant donné que notre ISO VirtIO est toujours rattaché à notre machine, rien de plus simple :
Il nous suffit d’exécuter le binaire virtio-win-gt-x64, et de choisir les drivers souhaités ! Selon plusieurs forums, il vaut mieux éviter d’installer le driver concernant le Ballooning, et de mémoire lorsque j’avais installé Proxmox sur un serveur dédié avec pfSense et autre (il y a de ça presque trois ans), j’avais aussi des soucis avec, donc autant prendre des précautions et ne pas l’installer, beaucoup se plaignant de dégradations de performances.
Comme on peut le voir, la carte réseau est désormais bien reconnue est fonctionnelle :
Et concernant notre AD lui-même, nos OU et users sont toujours bien là :
V) Conclusion
Et bien voilà, vous avez réussi à migrer un DC depuis Hyper-V vers Proxmox. Félicitations ! Comme vous le voyez, il n’y a rien de très sorcier, et plus encore si les drivers VirtIO sont installés avant la copie du disque de la VM (je n’avais pas testé avant de conclure cet article, mais je confirme que cela fonctionne).
Bref, au moins vous aurez les deux façons de faire !
Bien-entendu, c’était une première pour moi, et cela a été fait dans le cadre d’un lab. Impossible de dire si les performances seront équivalentes à Hyper-V, si certaines options peuvent être poussées plus loin en terme d’optimisation… libre à vous de donner votre grain de sel en commentaire ! J’y répondrais avec plaisir comme d’habitude.
Sur ce, je vous souhaite une bonne journée/soirée, et n’arrêtez pas d’expérimenter~
The last time I publishedarticles on the topic of email migration was in the long, long ago: in the before time. Yes, before pandemics and novel coronaviruses, but also before we had the option to remove the last Exchange server. Some have asked me if I would change any of my instructions or advice for migrating from Exchange on-premises to Exchange Online in light of these recent developments.
My short answer is: it depends, and even then, only if you want to.
For the longer version, read on.
Do you really need hybrid?
The first thing to note is that the new process for removing the last Exchange server is only going to be applicable to a minority of SMB tenants who require long-term hybrid identities with directory synchronization. Why? Because the vast majority of SMB’s should be focused on removing traditional AD anyway, and migrating toward cloud-only identities in Azure AD (as many have already done).
When someone says they absolutely cannot get rid of the local AD, that usually means there is either some legacy thinking, or a legacy Line of Business application standing in your way. This blog has often dedicated articles to dismantling the barriers related to the former problem, but when it comes to the latter (LOB apps), how should we address them?*
First, determine if there are actually dependencies here or not. For example, there may be web-and-mobile friendly alternative apps of which the stakeholders are unaware. If not, and you have to stick with the existing app, next you must ask: Does the application rely on Active Directory or Exchange mail attributes in any way? If so, you may have a legitimate reason to keep these systems around, if not, then proceed accordingly. Most of the time, the perception is different than the reality: most apps do not actually have a hard requirement for AD.
In some circumstances (where supported), legacy apps can be hosted in a virtual desktop environment by a service provider, or in Azure, leveraging Azure AD DS or a standalone pair of small-sized VM’s promoted as DC’s, along with Azure Virtual Desktop or similar. And of course, there is always the old refresh your server on-premises if none of these other options appeal to you.
Assuming you have exhausted your other choices (e.g. drop-and-shop) and you’re still stuck with a legacy AD (either on-prem or in the cloud), then your next step is to decide how important it is for you to keep the same credentials for this legacy app as you have for say, your email and cloud-based applications. Very important? Then consider keeping a hybrid connection. Not so important? Perhaps it is time to isolate this app from the rest of your (more modern) environment.
And what about legacy file shares?
Another place people get stuck is on larger-sized file migrations, particularly where there are lots of really large files like CAD drawings, etc. In this case you have similar choices to make. Just think of this requirement no differently than other legacy LOB apps.
How much of this storage is “current” and how much is just archival and can be pushed to an alternative cloud platform such as Azure Files or even a third-party cloud storage solution? Or, if you are going to elect to keep a local file system, will it be Windows-based and connected to the same identity/credentials as your email and other cloud apps? Or should you isolate this on a separate, purpose-driven system or alternative solution?
These choices will be up to you. Again I want to point out that this a niche case, and that the demand for this kind of solution is going to be an exception, not the rule. Most SMB’s with typical information workers can simply move files to OneDrive/SPO/Teams, and/or Dropbox, Box, Citrix ShareFile, or similar. In other words, cloud-based apps that can be connected to Azure AD for SSO and better security.
The hybrid path (only if you need to or want to)
Most of the time, small organizations are coming from older systems, such as Windows Small Business Server 2011, or Windows Server Standard 2008R2, 2012, 2012R2, or 2016, with Exchange Server 2010, 2013 or 2016 installed on top of one of those systems. If you are coming from anything older than that, then I would recommend a third-party tool to assist in the migration process. Otherwise, hybrid or “remove move” migrations will be the best migration option for you (or you can still use third-party tools if you prefer).
Once you are done with the migration, then you can either keep an Exchange 2016 or 2019 server around for hybrid purposes (like we have always done), or, now, you can choose to get rid of it. But for this option you will need to have Exchange Server 2019: so if you came from say 2016, add a 2019 server and run the latest cumulative update before executing the process to remove the 2016 as well as the last 2019 server. Remember that even after you “remove” the last Exchange server (really you’re just shutting it off forever), you are still dependent on the local AD for your identities and specifically for all the mail related attributes: the source of authority is still on-premises, and the Azure AD Connect synchronization must still remain in place just as before (so not that much has changed, really).
Review this Microsoft docs article for more details on how this “Exchange Server Free” hybrid environment looks in practice. Two main differences:
You will no longer have to maintain a server with Exchange installed on it for hybrid management purposes
You will no longer have the Exchange management web UI, and instead you will only have some PowerShell cmdlets with which to manage the attributes
Actually, Steve Goodman over at Practical 365 has provided a graphical web-based tool for managing the Exchange attributes after removing the last 2019 server. See this article for more details.
Okay, so the proper migration steps would be:
Make sure your source environment has latest available cumulative updates
Add your domain name(s) to Microsoft 365, verify (add TXT) but do not cut over MX yet
Configure Azure AD Connect to sync identities & on-premises passwords to the cloud
Run the Hybrid Configuration Wizard (HCW) / alt: third-party tool setup
Migrate public folder data (if applicable, usually try to replace w/ Groups, Teams, etc. instead)
Finalize your migration batches
Cut over MX records, SMTP relays, etc.
New post-migration and clean-up tasks:
If needed, add or upgrade to Exchange server 2019 (latest CU)
Remove older Exchange servers as applicable
Follow the process to shutdown the last Exchange 2019 server permanently (optional)
Moving forward, update processes to manipulate mail attributes using the new cmdlets
Consider configuring Hybrid Azure AD Join for your PC’s and configure device-based Conditional Access to improve security
Similar to how we have always done things, with a few extra items tagged onto the end.
Cloud-only identity (the preferred path)
As always, I encourage you to strongly consider severing your ties to that old beast known as Active Directory. Most folks can get by just fine (better actually) without it. In this case your migration looks very similar to the above, except that your post-migration tasks will include a different subset of items:
Remove Azure AD Connect + Exchange hybrid
Move shared files & other apps to the cloud or cloud-based alternatives (and setup SSO to Azure AD wherever possible)
Join PCs to Azure AD and configure device-based Conditional Access
Move DHCP from AD to firewall or router
Shut down the AD domain forever
In this configuration you are in the best possible position to implement additional security & compliance capabilities, and take full advantage of the other goodness the cloud has to offer, without carrying any of the baggage of days past.
I really do think that the hybrid path appeals to a dwindling subset of SMB organizations: the vast, vast majority of you should be looking to cut ties and go toward cloud-only identities, even if it means managing a separate credential set/security boundary for a legacy app in some cases (especially if it is going to be temporary). But, if you are one of those “special case” customers, we now have the option to maintain a hybrid environment, without necessarily keeping that old Exchange server around. Some may still prefer to keep the Exchange server, and that’s totally fine as well.
If I were forced to keep a legacy AD around, I personally would choose to kill the directory synchronization and just maintain a separate security boundary for that application specifically. But that is due to my own preferences and risk tolerances. You may come to a different conclusion. I won’t shame you for it, as everyone has a right to be wrong. At least now you know how to do the wrong thing the right way.
At Sympraxis, we often work with clients who have been using SharePoint for a long time. In many of these cases, they have been using SharePoint basically as a cloud-based file server. At some point in the past, they have done a lift and shift from “on premises” servers (wherever they may live) into SharePoint on premises or SharePoint Online. They are getting little value for their use of the platform, and they want to move up the Microsoft 365 Maturity Model.
One of the things we often need to do is migrate content from its current location into a more refined and purpose-built site topology and information architecture.
When we do that migration, we don’t want to delete the old site(s). Instead, we want to lock them from accidental updates and remove them from the search index. Since we’re migrating the content into new locations, we don’t want to old content to show up in search results.
The PowerShell below is useful in that it allows us to take care of those two steps easily. It’s meant as an example, but it is working code. You might more realistically wrap this in a foreach to apply to multiple sites at the same time.
$tenantName = "your tenant name here"
$spRoot = "https://$($tenantName).sharepoint.com"
$siteCollectionUrlFragment = "foo" # Part of the URL after /sites/, e.g., HRTeam, Marketing, etc.
# Work on this Site Collection
$siteCollection = "$(spRoot)/sites/$($siteCollectionUrlFragment)"
# Connect to Admin Center
$adminSiteUrl = "https://$($tenantName)-admin.sharepoint.com/"
$adminConnection = Connect-PnPOnline -Url $AdminSiteUrl -Interactive
# Connect to Site Collection
$siteCollectionConnection = Connect-PnPOnline -Url $siteCollection -Interactive
# Needed to set NoCrawl
Set-PnPSite -Identity $siteCollection -DenyAndAddCustomizePages $false
# Exclude Site Collection from Search Index
$Web = Get-PnPWeb -Connection $siteCollectionConnection
$Web.NoCrawl = $true
$Web.Update()
Invoke-PnPQuery
# Lock the site
Set-PnPSite -Identity $siteCollection -LockState ReadOnly
There probably aren’t a lot of people who use the Storage Management page in SharePoint these days, but I find it really helpful. When we do migrations it’s invaluable, especially when we are looking at a “legacy” – read: classic – pyramid of a Site Collection, with lots of nested subsites. Sure, there are fancier tools – our favorite at Sympraxis is ShareGate Desktop – but good old storman is a great starting point.
By adding the following to a site’s URL: /_layouts/storman.aspx, you’ll see an interactive view of your storage usage for the site. You can also get to the page from the Site Settings; the path varies a bit by SharePoint version, but the link in Site Settings is usually Storage Metrics. I find it’s easier just to type the page on an existing URL for a site.
Here’s an abbreviated example from a classic site we recently worked with a client on to “flatten” the classic subsites into modern sites. (With ShareGate, of course!)
The “containers” below the site are listed in descending order of size, and you can click on any one of them to see the sizes of the content within it, if you choose, all the way to individual files.
This gives us a good high level view of which content is going to take more of our effort. Here, the Company subsite is almost twice as large as its next largest peer.
It would be great if we could choose how to sort the view or filter it, but this is a very old page that Microsoft included first with SharePoint 2007, if I’m not mistaken.
Want to understand where your bigger challenges are going to be as you move from classic to modern or move content around in your modern sites? Storman can be a great help.
Vous avez GSuite, et vous devez migrer vers Microsoft365… Comment faire ? Quel(s) outil(s) ?
D’un côté GSuite avec des utilisateurs, des drives, des calendriers etc …
De l’autre Microsoft365 aka M365
Entrons dans le vif du sujet,
Microsoft propose une solution pour migrer les drive et la messagerie (incluant, contact, calendrier) avec quelques limitations indiquées sur le site de l’éditeur.
Voici le step by step pour les mails :
Depuis la console Admin 365 direction Exchange Online (une fois l’ensemble des comptes utilisateurs créé au préalable of course)
Suivez les indications à l’écran en sélectionnant bien GSuite
Vous pouvez utilisez la création automatique du projet de migration via Microsoft, en vous authentifiant avec votre login Admin Google.
Cela va initié un certain nombre de chose, dont une liste d’API à autoriser. Evidemment … pas complète … et vous télécharger un fichier JSON à conserver pour la création du point de terminaison dans 365.
Une fois que tout cela est fait, ajouter un CSV de cette forme
Choisissez les items à migrer, par date, type etc …
Enfin sélectionner le EndPoint, ou bien créé le et valider le avec le fichier JSON téléchargé.
La plupart des erreurs à ce niveau sont un mélange entre les noms de projet de migration google, les apis et les Json qui ne correspondent pas au batch de migration créé … bref ça fait spaghetti …
Une fois que tout cela est correct, y’a plus qu’a appuyer sur le bouton migration et attendre (pour faire simple) enfin migration … synchronisation plus exactement. Une fois la synchronisation terminée, il vous faudra compléter cette synchronisation pour mettre fin à la « migration » de la boite Gmail. Puis une fois que tout le monde à migrer opérer les redirections MX de Google vers Microsoft
N’oubliez pas que votre stratégie de migration est primordiale, et la communication avec les utilisateurs aussi, c’est bien de les faire déménager mais peut-être que certaines actions seront encore à réaliser de leur côté.
Pour la partie GDrive le principe est similaire et encore plus simple
Direction l’administration de SharePoint Online puis Migration et sélectionner Google
Vous arrivez sur une page similaire pour connecter Google à Microsoft (ici c’est du box mais c’est pareil pour les autres) rien de trop compliquer à faire ici authentifiez vous avec le compte Admin Google et Microsoft fait le reste (correctement)
Vous avez deux sections (Scan et Migration)
Le scan lui fonctionne tout seul :
Une fois lancé vous avez une liste de tout les drives partagés comme personnels et vous pouvez filtrer.
Une fois le(s) drive(s) choisi(s) copier les vers Migrations puis (vous vous souvenez du deuxième choix – celui à côté de Scan >> cliquer dessus)
Une fois sur migration, vous avez la possibilité d’exporter la liste de migration via CSV pour définir une cible (OneDrive, SharePoint, Teams) ou manuellement si vous voulez, mais ca peut être long …
Pour tout exporter, il ne faut sélectionner aucuns éléments (oui oui je sais)
Un élément intéressant est le mapping des identités qui lui ce fait tout seul (si vos identités sont correctes prenom.nom@domaine.com) mais aussi la possibilité d’ajouter des Tags (qui correspondent en générale a votre stratégie de migration (par pays par exemple))
Je reviens une demie seconde sur le mapping, si vos identités ne changent pas en termes de nomenclature, utiliser un mapping de domaine c’est plus simple, plus rapide, plus propre, et source de moins d’erreurs
Une fois le fichier envoyé, sélectionner les Drive a migrer ou via les Tags puis sélectionner « Migrate »
Cela fonctionne pareil pour les Drive Personnel, mais qui ont plus tendance à aller dans OneDrive (avec un fichier Excel et quelques formules c’est assez simple)
Ah oui …. une fois le batch lancé, vous ne pouvez pas re modifier le chemin d’accès de destination.
Et voilà !
En soit ce n’est pas bien compliqué une fois sorti des noms de domaine, DNS, etc … Pensez a arrêter le drive Google une fois migré et surtout prévenir les utilisateurs de ne plus utiliser Gmail une fois migrer, ou bien verrouiller les accès aux users qui ont migré.
Les outils de migration de marché vous apporterons plus de flexibilité ainsi qu’un pilotage beaucoup plus précis. Mais avec de la rigueur et un suivi impeccable vous avez de quoi vous en sortir
Connexion
