Tag Archives: sysvol

DC Promotion fails ‘FRS is Depreciated’

Posted on by
37

FRS is Depreciated KB ID 0001579

Problem

Error seen when attempting to add a new domain controller to an existing domain;

Verification of replica failed. The specified domain {Domain-Name} is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is depreciated.

The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain.

You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing.

Solution: FRS is Depreciated

 

Before proceeding you MUST ensure all your existing domain controllers are AT LEAST Windows Server 2008. Your domain and forest functional levels should be at Windows Server 2008 (AL LEAST). It would also be a good move, to make sure all your DCs are replicating cleanly.

You need to go to one of your legacy (existing) domain controllers, and carry out the following PowerShell procedure. 

First make sure that no one’s messed about with this before, issue the following command and make sure the migration process has not been previously started;

[box]

dfsrmig /getglobalstate

[/box]

Start the process.

[box]

dfsrmig /setglobalstate 1

[/box]

It can take a while, (even if you only have one Domain Controller!) Keep checking the status, with the command ‘dfsrmig /getmigrationstate’ until it says all the domain controllers have migrated to global state ‘Prepared‘.

Change the process to state 2 (Redirected).

[box]

dfsrmig /setglobalstate 2

[/box]

This typically completes a bit faster than the first state. Keep checking the status, with the command you originally used, until it says all the domain controllers have migrated to global state ‘Redirected‘.

Change the process to state 3 (Eliminated).

[box]

dfsrmig /setglobalstate 3

[/box]

As before, keep checking the status, with the command you originally used, until it says all the domain controllers have migrated to global state ‘Suceeded‘.

On the ‘Old‘ domain controllers, you need to disable the NTFRS service and stop it.

[box]

Set-Service ntfrs -StartupType Disabled
Stop-Service ntfrs

[/box]

Now attempt to promote your new domain controller again.

Related Articles, References, Credits, or External Links

NA

Setup up a Central ‘PolicyDefinitions’ Store (for ADMX files)

Posted on by
7

KB ID 0001339 

Problem

We have had ADMX files for group policies for ages now, they are the successor to the older ADM files. They only really trip you up if you have something unusual to do, (like roll out LAPS, or Forefront, or Customising Office Deployments.)

In most cases you will want to have a central store in your Windows domain, so the clients can see the ADMX files, (and ultimately enforce the policies within them). 

 

Solution

You probably already have ADMX files on your windows clients/servers,  look in C:\Windows\PolicyDefinisions. So if you have installed any new ADMX files, they will get put in this folder on your local machine, (or domain controller).

Do you already have a central PolicyDefinitions store? It’s easy  to find out, from any domain joined machine, run the following command;

[box]\\{Your-Domain-Name}\SYSVOL\{Your-Domain-Name}\Policies[/box]

If theres a PolicyDefinitions folder already there, half your work has been done for you!

Copying Files to the Central PolicyDefinitions Store

ADMX Files are usually accompanied by an ADML file, while the ADMX files live in the PolicyDefinitions folder, the ADML files are ‘location specific’, if you look in your PolicyDefinitions folder you will see another sub folder for your ‘locale’. Below you can see mine is en-US (English US) your ADML files will live in here.

IMPORTANT: As you can see, (below). I’ve navigated to the PolicyDefinitions folder ON A DOMAIN CONTROLLER, at the following path;

[box]C:\Windows\SYSVOL\sysvol\{Your-Domain-Name}\Policies[/box]

DON’T Try and copy the folder, (or ADMX and ADML) files to the network path of SYSVOL, or you ‘may’ get permission errors, (see error below).

You can simply copy the entire PolicyDefitions folder across if it does not already exist, or copy individual ADMX/ADML files (to the folder locations outlined above).

Now on your domain controller, Administrative tools > Group Policy Management console, create (or edit and existing policy). If you are setup correctly you should see this;

If something is wrong you will see this;

Copying PolicyDefinisions and ADMX/ADML Files: Access Denied

If this happens, you need to ensure you are NOT trying to copy folders or files to the network path of the SYSVOL folder, Open the LOCAL path to the SYSVOL folder directly on a domain controller.

Related Articles, References, Credits, or External Links

NA

Managing Forefront Endpoint Protection (FEP) with Microsoft Group Policy (GPO)

Posted on by

KB ID 0000604

Problem

FEP is Microsoft’s offering for antivirus, try to think of it as the corporate version of Security Essentials. Just about everything on the net for managing it seems to be geared to managing it with SCCM. Which is fine if you have SCCM, but what if you don’t? Thankfully you can manage it with group policy, even if information on how to do it is rarer than hens teeth!

With a Microsoft CoreCAL you can use the FEP client, so if you already have CoreCALs, then it’s a solution that can save you some cash on your corporate AV strategy.

Solution

Installing Forefront Endpoint Protection

The client software is available in x64 and x86 bit flavours, it is installed from a single executable (FEPInstall.exe). There is no MSI installer (yeah thanks Microsoft!) So if you want to roll it out on mass, you need to either install it using a startup script, include the software in your ‘Master/Golden Image’ and re-image you machines, or tear your hair out trying to work out SCCM.

Managing Forefront Endpoint Protection with Group Policy

1. First you need to download the policy definitions, copy the FEP2010.admx file to %Systemroot%PolicyDefinitions.

2. Then copy the FEP2010.adml file to %Systemroot%PolicyDefinitionsEN-US

Creating a Group Policy Central Store

3. If you have all your ADMX policy definitions in a central location, all your clients can use them. The correct place for them is in the sysvol directory, in a folder called policies (this is where your clients read their group policies from). To create the directory issue the following command;

[box]MD “%logonserver%sysvol%userdnsdomain%policiesPolicyDefinitions”[/box]

4. Now copy all your policy files into it, (from the folder we used earlier) with the following command;

[box]xcopy %systemroot%policydefinitions*.* “%logonserver%sysvol%userdnsdomain%policiesPolicyDefinitions” /S /Y[/box]

5. Then either create a new policy, or edit an existing one that’s linked to the COMPUTER objects you want to manage.

6. Navigate to;

[box]Computer Configuration > Policies > Administrative Templates > System > Forefront Endpoint Protection 2010[/box]

Here you will find the policy settings you require.

7. When you are controlling settings via GPO this is what you will see on the client machines.

Importing and Exporting Forefront Policy Settings

8. From the files you extracted earlier locate and run the FEP2010GPTool.exe. From here you can import and export all the policy settings from a particular group policy. Microsoft have published a set of policy settings which you can download for various server roles.

Note: By default each policy you import will merge with the existing settings in the GPO, unless you tick the “clear the existing Forefront Endpoint Protection settings before import” option.

Updates for Forefront Endpoint Protection

9. Windows uses it’s existing ‘Windows updates’ path for getting updates. If you have a WSUS server you will need to enable the updates in the ‘Products and Classifications’ section.

10. If you DONT have WSUS but you are behind a proxy, you can manage FEP proxy settings from the following policy.

Related Articles, References, Credits, or External Links

NA

SBS 2011 Missing Netlogon Share (Post Migration)

Posted on by

KB ID 0000809 

Problem

Whilst performing an upgrade from SBS 2003 to SBS 2011, I went on-site this morning to be told, “The new server does not have a NETLOGON share!”. As a result the clients who had authenticated to the old server had successfully ran their logon scripts. But the clients who had authenticated to the new server had not.

Solution

1. On the original (SBS 2003) server > Start > Run > cmd {Enter} > Run the following command;

[box]
net stop ntfrs
[/box]

2. On the original (SBS 2003) server > Start > Run > Regedit > Navigate to;

[box]
HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > NtFrs > Parameters > Backup > Restore > Process at Startup
[/box]

Change the Burflags DWORD value to D4 (Hexadecimal).

3. Then start the ntfrs service again.

[box]
net start ntfrs
[/box]

4. Now go to the NEW (SBS 2011) server > Start > Run > cmd {Enter} > Run the following command;

[box] net stop ntfrs [/box]

5. On the NEW (SBS 2011) server > Start > Run > Regedit > Navigate to;

[box]
HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > NtFrs > Parameters > Backup > Restore > Process at Startup
[/box]

Change the Burflags DWORD value to D2 (Hexadecimal).

6. Then start the ntfrs service again.

[box] net start ntfrs [/box]

7. Now wait approximately one cup of coffee.

Related Articles, References, Credits, or External Links

NA