So now I want to shift gears and talk about GPO importing.
So as I mentioned earlier, GPO importing is a little different from the backup and restore scenario.
GPO importing does use GPM c backups, but it works in a little different way.
So it's good for primarily recovering deleted GPOs.
So if a GPO gets deleted completely, you can create a new GPO and import a backup of the previous GPO
into it.
Or you can import settings from other domains in forests or import GPOs from other domains in forests.
So if you have, for example, a test domain or a test forest and you want to test out your GPOs there
first and then import them into your production forest.
That's the scenario where import comes in handy.
An import can use this feature called Migration Tables.
Migration tables have been around since the beginning of group policy, and they're designed to convert
certain types of data within group policy objects as they're being imported into the new domain.
So the scenario is you have, for example, restricted groups policy that is using groups that are defined
in the source domain.
Maybe it's your test domain.
And you want to convert them to the same or a different named group in the production domain.
And that's the purpose of migration tables.
So they can convert usernames.
They can convert computer names.
They can convert domain groups.
So domain local, global and universal groups and USC paths.
And see paths.
Typically where you'll find those is in folder redirection policy or in software installation policy.
Where you've got a reference to in the case of folder redirection, a path where you want to redirect
your folders or in the case of software installation, the path to the MSI file.
So in both those cases, you can redirect those unsee paths or remap them as you're importing the backed
up GPO.
And the final use case here is what are called free text or SSIDs.
And this is where you might have entered, let's say in restricted groups or user rights assignment
policy.
You might have entered in by hand the name of a group or a user, and it doesn't get resolved to say
ID per say.
And it's entered into the group policy settings field as just the name and the textual representation
of the name or the side.
And in that case, you can also convert those values as they're imported into the new domain.
Now migration tables only support policy settings.
There's no support for any of this kind of remapping of principles and U.N. sees in group policy preferences.
So if you're trying to move group policy preferences from one domain to the other, it's completely
useless for that, unfortunately.
And Microsoft doesn't really have a good solution there for that scenario.
So this is kind of what a migration table looks like.
And as you'll see in here, you have a source name.
In this case, there's a source of marketing users at Candle Ecom and it's a domain global group and
it's being mapped by a relative name into the destination.
And what that means is we're assuming that there's a marketing users in the destination domain and we're
going to remap it to marketing users at Steam Lab dot test or something like that.
So that basically lets you control how the name gets mapped as it goes into the destination domain.
So let's dig in and take a look at how this works.
I'm going to go ahead and do a migration so you can see what this looks like.