Showing posts with label Windows Server 2008. Show all posts
Showing posts with label Windows Server 2008. Show all posts

Friday, September 23, 2011

Got Windows Server 2008 or Windows 7 Client and want to play God?

I came across this information a long time back but never got a chance to implement it until last night. It's a quick hit way to gain 'God' like access to all of the administrative tasks that are available on your Windows Server 2008 or Windows 7 O/S.

All you need to do is to firstly create a new folder on your Windows 2008 or Windows 7 desktop by right mouse clicking on a blank space and then selecting the 'New' and then 'Folder' flash out menu options.

Once you have the new folder on your desktop it should look like any normal newly created folder icon similar to below

 Once you have this new folder created, right mouse click on it and select the 'Rename' option.

Now copy the text from the line below and rename your newly created folder with the exact text.

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Once you rename your new folder to the above text, the icon on the folder should change to a new icon denoting you have created a 'GodMode' access icon similar to the screenshot below


Now when you double click on the 'GodMode' icon, you will see a huge list of links that allow you to do all sorts of administrative tasks!



 Now, I wonder if the same cheat would work for a Windows 8 O/S?

Saturday, January 15, 2011

KMS Minimum Clients (Activation Thresholds)

I came across this issue during the week when I was reading into KMS licensing in a bit of detail and thought it might be something worth sharing as I hadn't realised there were a minimum number of activations required for KMS to operate. Here's the official text from Microsoft's website on the subject:


KMS requires a minimum number of either physical or virtual computers in a network environment. These minimums, called activation thresholds, are set so that they are easily met by enterprise customers.

For computers running:
  • Windows Server 2008 and Windows Server 2008 R2 you must have at least five (5) computers to activate.


  • Windows Vista or Windows 7 you must have at least twenty-five (25) computers to activate.


  • For Office 2010, Project 2010 and Visio 2010 you must have at least five (5) computers to activate. If you have deployed Microsoft Office 2010 products, including Project 2010 and Visio 2010, you must have at least five (5) computers running Office 2010, Project 2010 or Visio 2010.

Thursday, January 6, 2011

Hyper V Time Synchronization on a Windows Based Network

A very common query that I get asked to help out with in relation to Hyper-V installations is the small (but very important!) task of getting time synchronization working between the physical environment and the virtual environment.

There are a lot of blog posts out there at the moment covering this topic but I thought I'd throw my 2 Cents in based on the solution that works for me.

Background
 
Firstly, I need to explain a little about how time synchronization works in a domain environment.

When you install the first domain controller in your domain, this DC is the owner by default of all 5 FSMO roles within Active Directory. The PDC Emulator Role is the one that is responsible for Active Directory Time Synchronization.

When you add member servers or client computers to your new domain, they then default to using the PDC Emulator Role holder as their time synchronization source. If you move the PDC Emulator Role to another Domain Controller, then this will become the time synchronization source for that domain in place of the original DC.

When you install a Member Server into Active Directory and add the Hyper-V role onto that member server things start getting a little bit more interesting!

The physical Hyper-V host that is now a member server in your new domain will use the PDC Emulator Role holder as its time synchronization source as you would expect it to, however, when you add virtual machines to that Hyper-V host and the 'Hyper-V Integration Services' are installed onto each virtual machine, then that VM starts to synchronize its time from the Hyper-V host it is based on and not from the PDC Emulator Role!

This 'VM to Host' time sync generally isn't a problem when all of your domain controllers are physical machines as the Hyper-V host updates itself from a physical machine separate from the virtual environment and this keeps the internal VM's up to date.

What happens though when your PDC Emulator Role holder Domain Controller (gasp for air!) is based on the Hyper-V host as a virtual machine? You guessed it - time sync issues occur and the virtual DC's clock starts to move out away from the time on the Hyper-V host, which in turn then knocks the rest of the domain off-skew as they are- as mentioned above, configured by default to sync from the PDC Emulator Role Holder.

The Wrong Way
 
A lot of people - including myself for a long time - took the stance that to resolve this problem, the best and easiest solution was to just remove the 'Time Synchronization' tick box from the 'Integration Components Offered' section on the virtual Domain Controller that holds the PDC Emulator Role. Once this step was completed and the time within the virtual DC was configured correctly, this nearly always resolved the time sync issues on site. I use the word 'nearly' in that sentence though as this workaround didn't always work.

The Right Way
 
So what's the solution? A couple of months ago, I came across a blog post from Ben Armstrong -Virtualization Program Manager at Microsoft -covering this subject and specifically around the Hyper-V 'Time Synchronization Integration Service'. In this post, Ben states categorically that you SHOULD NOT disable the 'Time Synchronization Integration Service' on any virtual machine within Hyper-V and instead you should manipulate the Windows Time Service (w32tm service) from within the virtual DC to get the results that you need for a coherent time sync within your domain!

The link to Ben Armstrong's blog post is as follows:
http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx

To summarise his post and outline my steps when faced with time sync issues in a Hyper-V environment, I carry out the following procedure on all my VM's (most importantly, my virtual DC's):
 
 
Enable all of the Hyper-V Integration Services (see below)


Check each virtual domain controller's time source using the "w32tm /query /source" command

If the virtual DC is using the 'VM IC Time Synchronization Provider', you need to type the following commands into the command line within the virtual DC to leave the Hyper-V time sync enabled for VM reboots but not for when the VM is up and running:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0

(Select 'Yes' if requested after you enter this command)

w32tm /config /syncfromflags:DOMHIER /update

(This command tells the virtual DC to sync from within the Domain)

net stop w32time & net start w32time

(This command stops and then restarts the Windows Time Service)

w32tm /resync /force

(This command queries the Windows Time Synchronization Service again and should now detail the internal time server - hopefully the DC with the PDC Emulator Role)

At this point, your Virtual Domain Controller should use itself for time sync when it is online and it will use the Hyper-V host for when it is rebooting or coming out of a 'Saved State' and before the Windows O/S loads

Finally, all that is left to do now is to configure the Virtual Domain Controller and each Hyper-V host that you have in your domain to synchronize with an external time source provider (NTP Provider)

Note: Make sure to follow the instructions in this next paragraph exactly as you read them as clicking on the 'Internal Time Source' option will not give you the desired result!
 
Use this link from Microsoft to automatically configure an external authoritative time source by selecting the 'Microsoft Fix It' button half way down the page under the 'Configure the Windows Time Service to use an External Time Source':

http://support.microsoft.com/kb/816042

The 'Microsoft Fix It' button should initiate a wizard that will prompt you to enter your external NTP servers (you can enter two in here for redundancy) and will then configure the registry to reflect these changes automatically.

 As I'm based in Ireland, the NTP provider that I prefer to use is  - ie.pool.ntp.org


Hopefully this will help you to get a better handle on Time Sync in a Hyper-V environment.

Tuesday, October 19, 2010

Windows 2008 R2 RADIUS with Cisco ASA

I came across an issue last week when a customer had retired their old Windows 2003 RADIUS server and replaced it with a new Windows 2008 R2 server. They had their Cisco ASA device integrated for Authentication of remote IPSec VPN clients to Active Directory through the RADIUS server.

When the old Windows 2003 server was removed and the new Windows 2008 R2 server went in, naturally, the RADIUS had stopped working and needed to be reconfigured.

After playing around with this problem for nearly half a day I found the solution wasn't too technical but more a step by step configuration of both sides of the Authentication process (RADIUS and Cisco ASA) needed to be carried out exactly as outlined below.

One of the main differences of the old RADIUS on the Windows 2003 Server versus the new Windows 2008 R2 server is that the Windows 2008 R2 Server uses the new Microsoft Network Policy Server to provide RADIUS and NAC (Network Access Control) to the network.

When the NPS component is deployed out of the box, it comes pre configured with some policies that can conflict with how you want your Cisco ASA to communicate with it and these policies will need to be deleted and recreated to get the Cisco to communicate with it.

The following blog post outlines exactly the process needed to properly configure your Cisco ASA with a Windows 2008 R2 RADIUS / NPS Server:

http://fixingit.wordpress.com/2009/09/08/using-windows-server-2008-as-a-radius-server-for-a-cisco-asa/