Remove hidden network adapters from virtual machines after V2V/P2V

• Start command with elevated rights
• Type: set devmgr_show_nonpresent_devices=1 press enter
• Type: start devmgmt.msc
• Go to View and select Show hidden devices
• Expand Network adapters
• Right click the old network adapter and select Uninstall

Move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008

Export the DHCP database from Windows 2003:

1.                   On the Windows 2003 DHCP server, navigate to a command prompt
2.                   Type the following Command: netsh
3.                   Type the following Command: DHCP
4.                   Type the following Command: server <\\Name or IP Address>
5.                   Type the following Command: export c:\w2k3DHCPdb all

You must have local administrator permissions to export the data.

Import the DHCP database

1.       Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer.
2.       Install the DHCP Role on the server.
3.       Stop the DHCP server service on the server.  To do this, follow these steps:
a.       Log on to the target DHCP server by using an account that is a member of the local Administrators group.
b.      Click Start, click Run, type cmd in the Open box, and then click OK.
c.       At the command prompt, type net stop DHCPserver , and then press ENTER. You receive a “The Microsoft DHCP Server service is stopping. The Microsoft DHCP Server service was stopped successfully” message.
d.      Type exit, and then press ENTER.
4.       Delete the DHCP.mdb file under c:\windows\system32\DHCP folder.
5.       Start the DHCP server service.
6.       Right-click on the Command Prompt (cmd) and select run as administrator, to open the cmd prompt using elevated privileges.

Note You must have local administrator permissions to import the data.

7.       Type the following Command: netsh
8.       Type the following Command: DHCP
9.       Type the following Command: server <\\Name or IP Address>
10.   Type the following Command: import c:\w2k3DHCPdb
11.   Restart DHCP and verify the database has moved over properly.


Credit to Microsoft:

AD Design Best Practices

Found this article about AD Design Best Practices, give it a read.

All credit to the author (see link via Cool stuff to know: AD Design: Best Practices.)

Forest Design Best Practices
The forest design process includes the following best practices:
• Identify the number of forests and write a justification for each one.
• Identify the number of trees and write a justification for each one.
• Wherever possible, create a Protected Forest Root Domain.
• Wherever possible, create a Single Global Child Domain for production in each tree.
• Identify the number of additional domains required in each tree.
• Identify the scope and contents of each domain.
• Justify each domain.
• Choose the generic name for each domain.
• Once the domain structure for the production forest is complete, design the domain structure for the other forests you created.

Naming Best Practices
Use the following best practices to name your AD forests:
• Use standard Internet characters. If they work on the Internet, they will definitely work in your network. Avoid accents and solely numeric names.
• Use 15 characters or less for each name.
• For the root name, use a simple, short name that is representative of the identity of the organization.
• Follow all DNS standards and make sure the internal DNS name is different from your
external name.
• Finally, before proceeding, buy the name.

Production OU Design Best Practices
Keep the following rules in mind when you create OU structures:
• Think in terms of equipment and objects in the directory.
• Determine how you will implement the administrative delegation process.
• Identify standards for all administrative categories in the organization.
• Use the administrative service or function or the line of business to name OUs. These tend to be more stable than organizational structure.
• Limit your structure to five levels, three if you are not responsible for the finalization of the structure. Recommend a maximum of five levels even though ten are possible. This gives you some breathing room.
• Remember the four reasons for the creation of OUs: categorization, administration, delegation, and segregation.
• Each OU you create must add value to the system.
• Never create an OU that does not contain any objects.
• Never create an OU that does not have a specific purpose.
• If an OU reaches an empty state, consider removing it. This may not be necessary because it may only be temporarily empty. If not, remove it.
• Identify an OU owner for each one you create. If no owner can be identified, remove the OU
• Justify all OUs you create.
• If you find that two OUs have the same purpose, merge them. This means that the combination of owner plus GPO plus delegation strategy is the same for both OUs.
• Use default OUs to administer the whole domain. Domain controllers should be kept in the DC OU. Domain Administrator accounts and groups should be kept in the Users OU. Domain Administrator PCs should be kept in the Computers OU.
• Use the production domain OU strategy to define the OU strategy for other domains and forests.
• Don’t forget to define and put in place standards for the recurring creation and deletion of OUs. These will help control the proliferation of OUs in your directory.

AD Integration Best Practices
Use the following best practices during this process:
• Active Directory should be the core directory service. AD can be modified through a graphical interface. You can also use scripts to perform massive modifications with AD. AD also supports a powerful delegation model. Finally, it supports PC management, something few directory services can perform.
• Use AD as your single point of interaction. AD provides a single point of interaction because it is a distributed database that uses a multimaster replication process. Users can modify data in any regional office and it will automatically be updated through the directory.
• If you need to maintain data integrity between multiple directories, use Microsoft
MetaDirectory Services with Active Directory as your primary data source.
• If you need to install NOS-related applications that modify the schema, add them to the forest root domain before creating the child domains.
• If you need to integrate in-house applications to the directory, use AD in Application Mode. This will have no impact on your NOS directory.
• Integrate NOS-related and other applications to AD only if it is absolutely required. Schema modifications can be retired and reused, but only through a complex process that will involve replication throughout your distributed NOS directory.
• Maintain your Active Directory as a NOS directory first and foremost. This will limit the amount of replication in the forest and will make it easier to upgrade to future versions of Windows server operating systems.

Service Positioning Best Practices
Use the following rules to design your Service Positioning scenario:
• In large AD structures, place the forest-wide Operation Masters in a Protect Forest Root Domain.
• If your forest spans multiple sites, place the Schema Master in one site and the Domain Naming Master in another.
• Carefully protect the access to the Schema Master role.
• Place the RID Master and the PDC Emulator roles on the same DC.
• Create a dedicated PDC Emulator role in domains that have more than 50,000 users.
• Separate Global Catalogs and Infrastructure Masters if you can.
• Place at least two domain controllers per domain.
• If a small domain spans two sites, use at least two domain controllers, one for each site.
• Place a Global Catalog server in each geographic site that contains at least one domain controller.
• Enable Universal group membership caching in each geographic site.
• Place a domain controller wherever there are more than ten users unless the WAN link speed will adequately support remote logon attempts
• Add a regional domain controller whenever there are more than 50 users per DC, especially if it is a multipurpose server.
• Install the Domain Naming Service on every domain controller.
• Use application partitions to designate DNS replication scopes.

Best Practices for Site Topology Design
Use the following best practices to design your site topology:
• Use the default configuration for inter-site replication.
• Do not disable the Knowledge Consistency Checker.
• Do not disable transitive trusts.
• Do not specify Bridgehead Servers.
• Calculate replication latency between sites.
• Create sites according to network topology; Site Links and WAN links should correspond.
• Make sure that no single site is connected to more than 20 other sites.
• Each site must host at least one DC.
• Do not use SMTP for domain-centric replication.
• Do not use SMTP replication if at all possible.
• Use 128 Kbps as the minimum WAN circuit for a Site Link.
• Associate every site with at least one subnet and one Site Link, otherwise it will be unusable.
• Create backup Site Links for each site. Assign higher costs to backup Site Links.
• Create Site Link Bridges wherever there are two hops between sites to reduce replication latency.
• If your available network bandwidth can afford it, ignore replication schedules in all sites. Replication will be performed when required with this option, but it will be more demanding on WAN bandwidth.
• Enable Universal Group Membership Caching in all sites.
• Use Preferred Bridgehead Servers only if replication must cross a firewall.
• Size your DCs accordingly.
• Monitor replication once your forest is in place to determine the impact on your WAN links.

Schema Modification Strategy Best Practices
Use the following schema modification best practices:
• Don’t make your own modifications to the schema unless they are absolutely necessary.
• Use AD primarily as a NOS directory.
• Use AD/AM to integrate applications.
• Use MMS 2003, Standard Edition to synchronize AD and AD/AM directories.
• Make sure all commercial products that will modify the schema are Windows Server 2003 Logo approved.
• Limit your initial modifications to modifications by commercial software.
• Create a Schema Change Policy Holder role early in the AD Implementation Process.
• Document the Schema Modification Policy and Process.

This operation has been cancelled due to restrictions

If you received this error after uninstalling any application that takes over the HTML open command (including, but not limited to, Chrome & Firefox browsers) you may also need to change the HTM/HTML association in the registry.

  1. Start, click Run, type Regedit in the Open box, and then click OK.
  2. Browse to HKEY_CURRENT_USER\Software\Classes\.html
  3. Right click the value for the .html key and select Modify…
  4. Change the value from “ChromeHTML” to “htmlfile” (or from FireFoxHTML to htmlfile)

Repeat these steps for htm and .shtml keys if they exist. You may also want to check the xhtml and xhtm keys. Don’t want to edit the registry? Download this file (right click and choose Save target as…) Then double click on the file to run. From After uninstalling Google Chrome Links in e-mail don’t work any moreYou may need to restart Windows for the change to take effect.

via This operation has been cancelled due to restrictions.