AD: Changing Group Scope

Did you ever make the mistake of wanting to create a Domain Local Group but you accidently pressed OK without changing the Group Scope to “Domain Local”  (Default is Global). Don’t worry, you can still make this group a Domain Local Group. It just involves an extra step.

First open the group, change it to “ universal”, press apply and then change it to “Domain Local” and apply again.

Global to Universal:Global to Universal

Universal to Global:
Universal to Global

Group Policy: remove hibernation file

On some servers you might see the following file appearing on you system drive: hiberfil.sys

Hiberfil.sys

This file is a system generated file. The system uses this file when it goes into hibernation. For a server, this might not be necessary :-) .

You can delete this file by using the command: powercfg –h off.

You can also create a Group Policy (rather a Group Policy Preference) for it.

Open a Group Policy that is applied to all of your servers (or create one). Navigate to:
<Computer Configuration>
     <Preferences>
          <Registry>

Create a new “ Registry Item” with the following values / parameters:

Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Value name: Disable Hibernation on Servers

Value Type: REG_SZ
Value data: %systemroot%\system32\powercfg.exe -h off

GPP Disable Hibernation on Servers

Run gpupdate /force on your server and logoff. When you log back on on to a server it will run this command once and thus will remove the hibernation file.

oh, btw. If you can’t see the hiberfil.sys on your system drive, it might be because it is hidden. Open Folder Options and select “show hidden files and folders”  and deselect “ Hide Protected operating systems files”

Folder Options

PowerShell–Changing AD user attributes

Recently I was asked to change some User attributes in AD. As these changes we’re on a lot of users in one OU, I concluded it would be a good idea to try this in PowerShell. In this article you will find the steps I took.

First of all I used the Active Directory Commandlets from Quest Software, you can find them here. Second, make sure you start PowerShell as a domain administrator or someone who has delegated rights to change the attributes.

The users whose attributes had to change where all in one Organizational Unit. So I first tried to get all the users that we’re in this OU.

get-qaduser -ou "domain/ou/ou"

Now I had to pipe this to a second command which would set the attributes for each user in that OU. To set attributes you can use set-qaduser.

get-qaduser -ou "domain/ou/ou" | foreach {set-qaduser -identity $_.logonname -streetaddress "<address>" -PostalCode "<ZipCode>" -City "<City>" -StateOrProvince "<State>"}

The next part would be a bit trickier. I needed to change the format of the mobile phone number. It was in the format: 0031 #########, I had to change this to +31 #########. Basically I need to cut off the first 2 zero’s and replace it with a “+” sign.

I used the substring method for this. You can pass the substring method a single parameter: the starting position where we want to begin extracting characters. And to concatenate the “+” sign in front of the string, you can just use the + sign  …get it? :-)

get-qaduser -ou "domain/ou/ou" | foreach {set-qaduser -identity $_.logonname -MobilePhone ("+"+$_.MobilePhone.substring(2))}

note: you can shorten the last 2 commands, into 1 command.

RDP Component Architecture Poster

This poster provides a visual reference for understanding key Remote Desktop Services technologies in Windows Server 2008 R2. It explains the functions and roles of Remote Desktop Session Host, Remote Desktop Virtualization Host, Remote Desktop Connection Broker, Remote Desktop Web Access, Remote Desktop Gateway, Remote Desktop Licensing, and RemoteFX.You can use this poster in conjunction with the previously published Windows Server 2008 and Windows Server 2008 R2 component posters

image

download link

some other posters:

PowerShell: Last Logon

I wanted to write a powershell script to retrieve the last logon property of an Active Directory User. Here is  how I came to the final script.

First of all: to get the domain users, use the command:

  • Get-QADUser

This will return a list of all the domain users. As it will not return the property LastLogon, you have to include it. And for a better performance you can exclude the default properties

  • Get-QADUser  -IncludedProperties name,lastlogon

You will now have all your domain users and the property Lastlogon. To list them:

  • Get-QADUser -DontUseDefaultIncludedProperties -IncludedProperties lastlogon  | Select-Object Name,LastLogon

Next, to export it to a csv file (use the NoTypeInformation parameter to remove the .NET object header):

  • Get-QADUser -DontUseDefaultIncludedProperties -IncludedProperties lastlogon  | Select-Object Name,LastLogon | Export-Csv c:\ADusers.csv -NoTypeInformation

BTW: I used PowerGUI Script Editor

Troubleshooting FRS – SYSVOL Sync

A customer had a problem with synchronization between 2 domain controllers. Changes on the NETLOGON share on DC1 we’re not synchronized to DC2.

First thing to look for is events in the File Replication Service Event Log. On DC1 I did not find any events being logged but on DC2 I found a couple of warnings with eventid 13508:
The File Replication Service is having trouble enabling replication from DC1 to DC2 for c:\windows\sysvol\domain using the DNS name ad01gimd.directory.gimd.nl. FRS will keep retrying.……

So I restarted the File Replication Service on DC2. After the restart there was no warning anymore, just an informational message eventid 13516 stating:
The File Replication Service is no longer preventing the computer DC2 from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL…….

I did the same service restart on DC1. This did produce a event Error with eventid 13568, stating:
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is   : "c:\windows\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons…….

To resolve this error execute the following steps, just make sure you’re not using a post Windows 2000 SP3 Operating System, as this solution is not recommended to  use on this OS:

  • open the registry editor and navigate to the key:
    HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Paramaters
  • Create a new DWORD value named: “Enable journal wrap automatic restore”  and give it a value of 1
  • restart your File Replication Service

This should produce a warning in your File Replication Service Event log (13560) stating:
The File Replication Service is deleting this computer from the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" as an attempt to recover from the error state,
Error status = FrsErrorSuccess
At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set….

So I gave the server 5 minutes. After that I got some informational messages in the event log (13553, 13554, 13516)

13553

The File Replication Service successfully added this computer to the following replica set:
    "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

13554

The File Replication Service successfully added the connections shown below to the replica set:
    "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
      "DC2.<Domain>"
      "DC2<Domain>"

13516 The File Replication Service is no longer preventing the computer DC1 from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.

 

After creating a text file on one of the netlogon shares, it replicated correctly to the other domain controller.
Another problem solved, another happy customer :-D