Friday, February 25, 2011

Group Policy to Turn Off Display

If you want to turn off the user's monitor/display to save power and extend monitor life using Group Policy & Active Directory (Server 2008 R2, probably works in earlier versions as well), consider the following group policy setting:

  • Computer Configuration > Policies > Administrative Templates > System > Power Management > Video and Display Settings > Turn Off the Display (Plugged In or On Battery)
Just set a timeout value, and go!

There seems to be another setting which only applies to Windows Vista and above - "Turn Off Adaptive Display Timeout", which is pretty confusing based on the wording.  Here is what I think it does: you know how sometimes, your screensaver or monitor just begin to shut off when those timeouts are hit, but you move the mouse real quick to stop that from happening?  In that case, I have seen that even though the machine begins to activate the screensaver, lock the screen, or shut off the monitor, you can sort of "catch it" before it finishes and it lets you right back in.  That's the adaptive part - the system detects this condition where you just about timeout but catches it before it finishes happening.  Based on how much this happens to you, Windows automatically adjusts the Display timeout value to try to prevent timeouts from being annoying.

The group policy wording states: "When this policy is enabled, Windows automatically adjusts the setting based on what users do with their keyboard or mouse to keep the display on. When this policy is disabled, Windows uses the same setting regardless of users’ keyboard or mouse behavior. If you don’t configure this setting, users can see and change this setting.".  It's confusing because they say "Turn Off" is "enabled" - but I think what they mean is, the adaptive timeout for turning off the display policy is enabled or disabled.  That makes more sense to me at least.  I will test it and see what happens.

There is also nice post over on the Microsoft Directory Services team blog that discusses other power management options with AD.

Thursday, February 24, 2011

Reach out and ping someone!

If you are testing network connectivity, packet loss, latency, etc. and you need an external server to ping (ICMP echo request), consider using the IP  This IP represents Google's public DNS.

Funny, in the past, I remember using and never knowing exactly who it was that ran that IP.  Turns out, as with most things strange and interesting on the net, there is a small story behind that IP.  Kudos to for posting it!

Tuesday, February 22, 2011

Identifying a Network Device by MAC/Hardware Address

If you are trying to identify a network device, and all you have is a MAC address for that device, you might try identifying which hardware vendor the MAC address range is associated with.  For example, I had a device connected to my wireless which had a MAC address starting with the prefix 30:69:4B.  I could not identify exactly which device it was, although it was most likely a valid one.

The device also did not show up in other tools, such as the Windows command line arp -a command, Angry IP Scanner or Colasoft's MAC Scanner, so identifying it that way was not possible.  ARP stands for Address Resolution Protocol, i.e. the protocol used to determine MAC addresses from IP addresses so that transmission at the link layer can occur.  You didn't forget your OSI model did you?  :)

Using I was able to determine the device was a coworker's Blackberry phone which was associating with the wireless access point (AP).  The MAC prefix is owned by the manufacturer RIM/Research In Motion.  Another similar search site is Vendor/Ethernet/Bluetooth MAC Address Lookup and Search, although I didn't find what I was looking for on that one.

Monday, February 21, 2011

Enable Remote Desktop in Server 2008 R2 Active Directory Group Policy

If you need to configure Windows Server 2008 R2 Active Directory group policy so that Remote Desktop is enabled on a domain, note that it is no longer referred to as Terminal Services in the Group Policy Management interfaces, it was renamed Remote Desktop Services.

Two group policy changes should do the trick, followed by a gpupdate /force or waiting for the policy to be distributed to domain members/clients:
  1. Computer Configuration > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Allow inbound Remote Desktop exception.  Note that I recommend limiting the IP addresses that have access as explained in the notes of that policy, if possible, as a best practice.
  2. Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely using Remote Desktop Services
Now you should be able to remote desktop into any domain member which the policy is applied to!

    Local Profile Migration with USMT

    I recently had to migrate about 20 domain accounts from a small, dying, badly designed Windows 2000 domain controller to a newly named and properly configured Windows 2008 R2 domain.  The domain names had to be different between the two systems, and all the users were using local Windows profiles on XP or Windows 7.  The customer didn't want to implement roaming profiles or folder redirection due to concerns about the extra burden on the network.  This meant I had to migrate the local user profiles from one domain to another.

    I tried using several different tools, including: Microsoft's Active Directory Migration Tool version 3.2 (which is probably best for Server 2003 -> Server 2008 and above migrations in larger enterprises, where both AD servers are functioning normally and the old one still is online), evaluated the built in Easy Transfer or the Files and Settings Transfer Wizards, and ended up with the User State Migration Tool (USMT).

    USMT can basically copy the files from one profile to another, to a local disk or to a network share.  This had to be done in order to change the association of the profile, unfortunately, from the old domain to the new one.

    Here are some useful download links:
    I will post a follow up with more instructions on how I applied these tools soon, and the issues/workarounds I encountered.  I highly encourage testing the USMT tools, as my migrations have worked but things didn't exactly go flawlessly (the most problems revolved around Outlook settings).

    I don't know how the heck a large organization would use any of these tools to successfully migrate like I did without some degree of manual intervention.  What a headache!

    Also, quick tip - for small Active Directory domains that might grow up into larger ones some day, the best internal Active Directory domain naming scheme is an unused corporate public domain or subdomain that you own and will keep for a very long time.  For example, I might own and  Therefore, you might use for your internal domain name, or if you are not using it for anything else.  I DO NOT recommend using anything else, including .lan or .local.

    First Post!

    Greetings, and welcome to No Joke IT.  I have a favorite saying in the information technology business - that IT vendors build or invent wonderful technologies in their "infinite wisdom", and then don't bother to document them for the rest of us.  Hey, we all do it!  Anyway, I will try to share tips and hints that crop up as I go along, so that other IT folks searching (just like I am) will find the solution to that odd problem that isn't documented anywhere else.

    It's always great to get first post, even on your own blog! :)