Hyper-V Networking and VLAN Configuration Scenario

I have written the 2nd part of the Hyper-V Networking and Configuration.

The big difference that we see between Scenario 1 and Scenario 2 is the communication to the External LAN (e.g. VM1 through VM3 talking to Server1 through Server3 on LAN). The moment you see the requirement for External communication you’ll think of using an External Virtual Switch.

To achieve the requirements of this second scenario, you can use any of the configuration methods as discussed earlier but the most suitable methods to use are:

  • Using another Physical NIC Method (applies when External networking is configured).
  • Using Hyper-V Virtual Switch and VLAN Tagging Method.

And the scenario looks like below:

More explained at http://www.simple-talk.com/sysadmin/virtualization/microsoft-hyper-v-networking-and-configuration—part-2/


Microsoft Hyper-V Networking and Configuration Part 1

Most of the article talks about Hyper-V Networking. It doesn’t really elaborate on basics of Networking. Instead the article focuses more on the Hyper-V Networking and VLAN Tagging with examples.

The first article in this series explains the following topics:

  • Virtual Networking Overview
  • Hyper-V Virtual Network Switch Overview
  • Microsoft Hyper-V Virtual Network Switch Types
  • Microsoft Hyper-V Virtual Network Maximum configuration
  • What happens when you create a Virtual Network Switch?

Continue reading here.

The 2nd part of this article series will be posted soon.

Best, N

Tip – A Quick Tip To Update Group Policy Settings On Remote Computers

This article explains a single command you can use to update the Group Policy settings on remote computers. Please note this applies to Windows 2000 Computers only

Read more here…


WinInstall LE, MSI Creator and Configuration Builder

This article explains the advantages of tool WinInstall LE (a tool from Veritas software, which ships with Windows Server CD) and how to use this tool to convert EXE applications to MSI packages.

About Active Directory and Group Policy

You have, no doubt, heard about Active Directory. Active Directory is Microsoft’s answer to Novell Directory Service. Active Directory is a big repository of objects. It contains objects such as users, groups, shared printer information and network objects. Active Directory was first introduced in Windows 2000.

There is a tool or snap-in called Group Policy. Group Policy is meant for administrators who want to have a better control over systems running in network. Group Policy is used to control the behaviour of desktop computers and member servers from a central location. There are couple of settings you can deploy using Group Policy on remote computers. Group Policy comes with pre-defined administrative templates. Administrative Templates are the configuration unit as shown in Figure 1. You use them to control the behaviour of a specific setting, such as Start Menu and Taskbar, Internet Explorer Options settings, Registry Keys, Services and so on.

Read more here…


Tip – A Quick Tip to configure Group Policy settings in Workgroup Security Model.

This article will show how you can quickly configure Group Policy in Workgroup Security Model. This article applies to Windows 2000, Windows XP and Windows 2003.

The Group Policy can also be deployed in Workgroup security model but there is no central tool available to configure all computers in one go. For example, you have 20 computers in your network. You need to configure the same Group Policy settings on 20 computers.

Read more here…


Login Scripts, Computer and User Logon Scripts! – Difference

You may have noticed the following policy settings in Group Policy and for a while confused about these policy settings for user.

There are three places in Group Policy where you can configure programs to run when a computer starts and after a user logon to the system. These three places are under the following container:

  • User Configuration\Windows Settings\Scripts (Logon\Logoff)
  • User Configuration\Administrative Templates\System\Logon
  • Computer Configuration\Administrative Templates\System\Logon

In the last two, you will see the following policy settings:

  1. Run these programs at user logon
  2. Do not process the run once list
  3. Do not process the legacy run list

The above policy settings appear in both: User and Computer Configuration container.

For “Run these programs at user logon” policy setting, if this policy setting is configured in both the container (user and computer) the user policy setting will run just after computer policy setting.

For last two “Do not process the run once list” and “Do not process the legacy run list” policy settings, if this policy setting is configured in both the container (user and computer) the computer policy setting will take precedence over user policy setting.

Why so? The reason is very simple. The Run Once list is configured in Local Machine HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce only. The programs in this registry key are processed only after user has logged on to the system. There is no RunOnce key for user. That is why computer RunOnce will run after user RunOnce.

Now, you may ask that there is logon programs, login scripts and logon scripts but there is no Logoff Programs? It is because a program requires system resources when it runs whereas a logoff shuts down all the applications. While a windows is shutting down a program can not stay in memory.

There is a difference between running a program and a script. Please note the difference. A program is something which is installed on users computer and you configure in “Run these programs at user logon” by specifying the full path of that program. This program runs Locally. On other hand, a script is something which is run over the network. You need to specify a complete path of the program you wish to run when a user’s login script has finished.

So the point is very clear and the script or programs are run in the following order:

  1. Computer Startup / Script runs.               Will be applicable to all the computers
  2. User Login script runs. Will be applicable to all the users.
  3. Computer logon programs run Will be applicable to all the computers.
  4. User logon programs run Will be applicable to all the users.

After user login script has finished, the Winlogon at workstation will retrieve a list of programs to run on local computer from GPO.

In above, there is no conflict in policy settings so all the program will run one by one.

Group Policy Key terms:

Not Configured

This means Policy setting is not configured and Winlogon service at client end,

While processing the Group Policy Objects from domain controller, will not process this policy



This means Policy setting is configured but Domain Controller will not publish it for

processing or Winlogon at workstation will not process this setting.


This means Policy setting is configured and will be processed by Winlogon service at


The Microsoft has designed two options for Group Policy for NOT processing Group Policy settings. The “Disabled” option in Policy settings are configured per policy setting whereas “Disable User or Computer Policy settings” in property of GPO is used to NOT to process any policy settings configured in the said container. The later option overrides settings configured in earlier option.

  1. Computer policy settings only run when computer starts just before user logon. Example, you have a network drive to map for all computers. This network drive mapping will be available for all the users who log on to that system.
  1. User policy settings only run after user log on to the system. In above example, the network drive mapping will be available to all users who logs on to the system.
  1. Third option is filtering Group Policy settings using groups. This option doesn’t necessarily defeat the above rule but is here to process the GPO for selected users or computers. In above example, if you create a Group called “ServiceComputers” and put 4 computers in that group and apply a policy setting to this group then only the computers will receive this policy.

Other options are “Block Policy Inheritance” and “No Override”. The first option can be set on a child policy meaning you can not set this option at site level or there is no use of this option at parent policies. This option, if enabled, forces child GPO not to accept any policy settings coming from Parent GPO. The “No Override” option, if enabled, forces child GPO not to block any policy setting coming from parent GPO. If there is a conflict in the policy, the Parent GPO settings will be applied provided “No Override” option is enabled.

Why Default Domain GPO..Why…Why…Why

You might have few questions to yourself:

1. Why domain GPO will still apply to local admin account of client computer.

2. Why domain GPO will still apply in safe mode and safe mode with networking modes.

Interesting when you see domain GPO will still apply to a computer not connected to network.

This behaviour is by design. This is just to maintain the security of computer.

The reason and Logic behind this

Its all about the Computer Account and relationship of client computer with domain. Windows OS and Winlogon service still assumes that a PC logged on to local computer or safe mode/with networking is the member of domain as long as Computer account of this local computer exist in domain or a secure channel exists between computer and Domain Controller.

Windows OS assumes that the security of this computer should be maintained by a domain controller as long as it is the member of the domain. So GPOs will be applied when you log in Safe Mode or any other mode.

Group Policy to close off all programs before backup runs.

Let’s say you want to implement a policy setting that can be used to close off all the programs running in computer.

Actually speaking this is not bit easy but you can deploy a script that can do your job at specifed time using Task Scheduler service.

To accomplish above you need the followings:

1. A startup or logon script.

2. tlist.exe to display list of processes running on the computer and kill.exe to kill the processes running except Windows defaults.

3. AT command to schedule the script at specified time.

You need to know the *process name* of the application you want to close or kill. You can use resource kit tool called “kill.exe* to close the process of an application. When you kill the process, application will be closed automatically.

You need to run a script using Group Policy which will run at 10.00 PM everyday. You can achieve using Task Scheduler  service or using AT command in a script. Deploy this script using Group Policy.

Files opened by network clients must also be closed in order to perform backup. You can use the command outlined here to close all opened files by network users.  

Please follow this article:


If you don’t know what all applications clients are running then you need to use some kind of programming stuff which can identify and close the application. Likewise all running applications can be closed by killing the main process that is Explorer.exe. But if you kill explorer.exe then you need to re-run it in order to perfrom backup. Using some programming stuffs you can acheive this. Here is an example:

1. You create a script.
2. Use kill.exe in this cript to end PID of explorer.exe or kill this process.
3. Run a command again to re-start this process (explorer.exe) to lunch desktop and then perform backup.

Group Policy Rule


Keep the following rules in mind before you apply the Group Policies:

1. Group Policies can be applied to AD-Leaf objects such as users and computers but NOT security or distribution Group.

2. Users and Computers MUST reside in the OU where you have configured Group Policy.

3. Group Policies can use GROUPS to filter the scope of policy settings.

4. By default Group Policies are applied to the following groups:

Authenticated Users                                        

5. If the security properties are default….then Group Policy settings should apply to administrators or you because by default when you create a GPO the following Security Settings permissions are set:
*Apply Group Policy* and *Read* Permission to the following Groups:-

Authenticated Users                                        
Domain Admins                                            
Enterprise Admins

5. Group Policy processing depends on Client-Side-Extensions stored in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPTExtensions << all GUID listed for Client-Side-Extensions.

CSCs are used to process GPOs from Domain Controller. Winlogon.exe will capture a list of GPOs.

As per M$ recommendation you should remove *Authenticated Users* group and create a new Group > add all members to this group and use FILETERING technique. Now generally what happens all user objects are member of

Authenticated Users Group and the settings are mixed because from Domain Level to………child OU the settings are applied to Authenticated Users Group………so for example :-

If you have configured anything in the parent OU and also configured in Child OU…and all users are member of Authenticated Users Group….settings are meesed up and then Group Policy rule is applied:

Policy Settings at Parent OU                  Policy Settings at Child OU                    Result
If NOT Configured                                    If Configured                                       Child’s setting applied
If Configured                                           If Configured and Do not conflict            Both Settings
If Configured                                           If Configured and Conflicts                    Child’s setting applied
If Configured                                           If Not Configured                                  Parent’s Setting applied
If NOT Configured                                    If Not Configured                                  No Settings (This is default)

Copy Group Policy Settings.



You need more than one Group Policy Objects and few settings are similar and few are not but the amount of configuration is time consuming. You can avail this by copying the Group Policy settings from SYSVOL folder to destination GPO.

You will see policy contents of GPO created in SYSVOL folder in Policies sub-folder and then copy them to the newly created GPO.

This is how you do it:

A. First note down the GUID of Old GPO you want to copy:

1. Open ADUC
2. Right click on OU > Property
3. Switch to Group Policy tab
4. Click GPO > Property > note down the GUID of this GPO.

B. Next create the new GPO and find out the GUID in the same manner.

C. Follow the steps outlined below to copy contents of old GPO to new GPO you created in step B.

1. Finally goto SYSVOL\domain_name.com\policies\GUID of old GPO
2. Copy the contents of this GPO.
3. Next goto SYSVOL\domain_name.com\policies\GUID of new GPO
4. Paste the contents here or overwrite.

D. Finally make whatever changes you want to make to the copied policy.