Export/Import certificate templates from AD in Windows 2012

Today there will be a few words about importing and exporting certificate templates in Microsoft Active Directory.
This data is stored in the AD configuration partition and is thus shared by all domains within the AD forest.
Sometimes, however, there are situations where there is a need to move this data between forests, for example, when deploying a solution under test in a pre-production environment to a production domain.
Such a task can be done in two different ways. The first is obvious to those who have a lot of experience with windows, but this way is ugly and can cause major complications in today's systems. Therefore, I will discuss it later.
With the advent of Windows 2008 R2, a new AD CS role has been introduced, which is calledAD CS Web Enrollment Service.
It is intended to serve the publication and use of CA between AD forests, assuming only the existence of an External Trust Relationship between these forests. More on this topic can be found here.
The same page also included two great scripts written in powershell, which are the crux of today's post. With them, you can export and import templates to and from XML files in the following format MS-XCEP.
Unfortunately, these scripts have two bugs that show up when working with Windows 2012:

1. scripts were written as regular CMD-Let's, which unfortunately are not loaded in W2k12. A quick workaround for this problem is to comment out the function declaration with a closing curly bracket at the beginning and end of the script. Also, comment out the parameter declaration as cmd-let binding. After these changes, the scripts will run in the normal way with the ability to provide the appropriate input as required.
2. The export function has improperly implemented support for verifying the existence of one of the template's array attributes. Line:

   1	$supersed = if ($temp.Settings.SupersededTemplates -eq 0) {

   Replace with the following:

   1	$supersed = if ($temp.Settings.SupersededTemplates.Length -eq 0) {

   Thanks to this procedure, both exports and imports will be successful.

3. The final inconvenience of these scripts is the dependence on the external Power Shell module. Since the module is written in .NET, it is certainly possible to eliminate this dependency, but this topic will be the subject of another post.

The "ugly method" mentioned earlier is the old ldifde command along with the required flags for export:

The most important part of this command is the -m switch, which results in the resulting ldf file devoid of references to AD Forest objects.
To import the generated file you need to use a very similar command...:

This method should work for all systems, starting with Windows 2000.