Error message when you restart Windows Server 2008 R2 after you perform a full OS recovery: “Windows failed to start. Status: 0xc000000e”


Symptoms
When you restart for the first time after you perform a full OS recovery of Windows 2008 R2, you receive the following error message:
Windows failed to start. A recent hardware or software change might be the cause. To fix the problem:

1. Insert your Windows installation disc and restart your computer.
2. Choose your language settings, and then click "Next."
3. Click "Repair your computer."

If you do not have this disc, contact your system administrator or computer manufacturer for assistance.

Status: 0xc000000e

Info: The boot selection failed because a required device is inaccessible.
Cause
When you perform a new installation of Windows Server 2008 R2 from a DVD to unallocated space, two partitions are created. During a recovery operation, the contents of the Boot folder are first restored from the ASR Writer backup and then restored again from the backup on drive C. This double restore action causes an inconsistency in the drive GUID definitions within the Boot folder data. This inconsistency leads to the boot error.
Resolution
To recover from this error, use the bcdedit command-line tool. To do this, follow these steps:
1.    Start the server by using Windows Server 2008 R2 media.

2.    Select Repair your computer.


1.    Select Command Prompt.
2.    At the command prompt, run the bcdedit command. Lists of items appear under Windows Boot Manager and under Windows Boot Loader.
3.    Look for the values for the following items :
a.     Under Windows Boot Manager, the Device item should be set to unknown.
b.    Under Windows Boot Loader, theDevice and osdevice items should be set to unknown.

1.    Run the following three commands to correct the settings, and then restart the computer:
a.     bcdedit /set {default} device partition=c:
b.    bcdedit /set {default} osdevice partition=c:
c.     bcdedit /set {bootmgr} device partition=c:
2.    Or, locate X:\Sources\Recovery, and then run StartRep.exe to start a quick automated startup repair utility that corrects boot environment values.
Note This issue occurs only with certain backup tools. When most backup tools are used, you experience no GUID corruption.




How to See Which Group Policies are Applied to Your PC and User Account through the Command Line


Intended for administrators, the Group Policy Results (GPResult.exe) command line tool verifies all policy settings in effect for a specific user or computer. Administrators can run GPResult on any remote computer within their scope of management. By default, GPResult returns settings in effect on the computer on which GPResult is run.

To run GPResult on your own computer:
  1. Click StartRun, and enter cmd to open a command window.
  2. Type gpresult and redirect the output to a text file as shown in Figure 1 below:

gpresult /scope computer /v >gp.txt
gpresult /scope user /v >gp.txt
gpresult /r >gp.txt

  1. Enter notepad gp.txt to open the file. Results appear as shown in the figure below.

Administrators can also direct GPResult to other users and computers. Complete parameters of the tool are shown in the table below.

Using GPResult Command Line Tool
Parameters
Function
/s Computer
Specifies the name or IP address of a remote computer. (Do not use backslashes.) The default is the local computer.
/u Domain\User
Runs the command with the account permissions of the user that is specified by User or Domain\User. The default is the permissions of the current logged-on user on the computer that issues the command.
/p Password
Specifies the password of the user account that is specified in the /u parameter.
/user TargetUserName
Specifies the user name of the user whose RSOP data is to be displayed.
/scope {user|computer}
Displays either user or computer results. Valid values for the /scope parameter are user or computer. If you omit the /scope parameter, gpresult displays both user and computer settings.
/v
Specifies that the output display verbose policy information.
/z
Specifies that the output display all available information about Group Policy. Because this parameter produces more information than the /v parameter, redirect output to a text file when you use this parameter (for example, gpresult /z >policy.txt).
/?
Displays help at the command prompt.

How to See Which Group Policies are Applied to Your PC and User Account through a GUI


1.    The easiest way to see which Group Policy settings have been applied to your machine or user account is to use the Resultant Set of Policy Management Console. To open it, press the Win + R keyboard combination to bring up a run box.
2.    Type rsop.msc into the run box and then hit enter.

3.    You will see a pop-up dialog for the small period of time it take Windows to query your system.
4.    Once the console opens you will be able to see which settings have been applied to your PC.
Note: Only settings that have been applied to your machine and user account will show up.

Robocopy command to copy files and folders with permission and other attibutes


Robocopy "\\192.168.12.1\E$\Important_Data\Data_New" "\\192.168.14.2\E$\Important_Data\Data_New" /S /ZB /MIR /COPYALL /R:3 /W:3 /NP /LOG:Data_Copy.log

/S
Copy Subdirectories, but not empty ones.
/ZB
Use restartable mode; if access denied use Backup mode.
/MIR
MIRror a directory tree (equivalent to /E plus /PURGE).
/COPYALL
COPY ALL file info (equivalent to /COPY:DATSOU).
/R:n
Number of Retries on failed copies: default 1 million.
/W:n
Wait time between retries: default is 30 seconds.
/NP
No Progress - don't display percentage copied.
/LOG:file
Output status to LOG file (overwrite existing log).
/PURGE
Delete dest files/dirs that no longer exist in source.
/E
Copy subdirectories, including Empty ones.


Windows: List Shared Drives and Folders from the Command Line

This Procedure applies to Windows XP Professional, Windows Vista, Windows Server 2003 and Windows Server 2008.
1. Open a command prompt.
2. Execute the following command:

wmic share get caption,name,path

A list of all shared drives and folders will appear, including the path for each shared folder.
If you want to generate a text or HTM file for printing, execute the following:
To generate the output as textfile:

/output:d:\Shared.txt share get caption,name,path

To generate the output as HTM file:

/output:d:\Shared.htm share get caption,name,path

make sure to change the location and filename (d:\Shared.txt or d:\Shared.htm) to the desired values.


Saving and restoring existing Windows shares

SUMMARY
If you need to complete any of the following procedures, you can save the share names that exist on the original Microsoft Windows installation, including any permissions assigned to those shares:  
·         Reinstall Windows over an existing installation (a clean install, not an upgrade).
·         Move all of your data drives from one server to another.
·         Install Windows to another folder or drive on a computer that already has Windows installed.
MORE INFORMATION
To save only the existing share names and their permissions on Windows follow these steps.

Note This procedure applies only to NetBIOS shares and not to Macintosh volumes.
1.    On the existing Windows installation that contains the share names and permissions that you want to save, start Registry Editor (Regedt32.exe).
2.    From the HKEY_LOCAL_MACHINE subtree, go to the following key:
SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
3.    Save or export the registry key.
·         For Windows NT and Windows 2000, click Save Key on the Registry menu.
·         For Windows Server 2003, click Export on the File menu.
4.    Type a new file name (a file extension is not necessary), and then save the file to a floppy disk.
5.    Reinstall Windows.
6.    Run Registry Editor (Regedt32.exe).
7.    From the HKEY_LOCAL_MACHINE subtree, go to the following key:
SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
8.    Restore or import the registry key.
·         For Windows NT and Windows 2000, click Restore on the Registry menu.
·         For Windows Server 2003, click Import on the File menu.
9.    Type the path and file name of the file that you saved in steps 3 and 4.

Caution This step overrides the shares that already exist on the Windows computer with the share names and permissions that exist in the file you are restoring. You are warned about this before you restore the key.
10.  Restart the server.
Note After you complete this procedure, if you decide that you should not have restored the Shares key, restart the computer and press the SPACEBAR to use the last known good configuration. After you restore the shares key, the shares can be used by network clients. If you run the net shares command on the server, the server displays the shares; however, File Manager does not display the shares. To make File Manager aware of the newly restored shares, create any new share on the server. File Manager displays all of the other shares after you restart the server or stop and restart the Server service.

In Windows NT 3.5, if you click Stop Sharing in File Manager, the restored shares are still displayed, but they are dimmed.

Only permissions for domain users are restored. If a local user was created in the previous Windows NT installation, that local user's unique security identifier (SID) is lost. NTFS permissions on folders and files are not affected when you save and restore the shares key.

Properties
Applies to

Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Web Edition, Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Professional Edition, Microsoft Windows NT Server 3.51, Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows NT Workstation 3.1, Microsoft Windows NT Workstation 3.5, Microsoft Windows NT Workstation 3.51, Microsoft Windows NT Workstation 4.0 Developer Edition, Microsoft Windows NT Advanced Server 3.1, Windows Server 2008 Datacenter without Hyper-V, Windows Server 2008 Enterprise without Hyper-V, Windows Server 2008 for Itanium-Based Systems, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 for Itanium-Based Systems, Windows Server 2008 R2 Standard, Windows Server 2008 Standard without Hyper-V, Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Standard

KMS Activation Method's:

Method 1:
Command to Configure the KMS Client Setup Keys
Always run the command in elevated command prompt.
  1. Open Command prompt: Run the following command as per the OS:

  slmgr.vbs /ipk D2N9P-3P6X9-2R39C-7RTCD-MDVJX  - For WIN2K12 R2 Standard Edition
  slmgr.vbs /ipk XC9B7-NBPP2-83J2H-RHMBY-92BT4  - For WIN2K12 Standard Edition
  slmgr.vbs /ipk BN3D2-R7TKB-3YPBD-8DRP2-27GG4  - For WIN2K12
  slmgr.vbs /ipk YC6KT-GKW9T-YTKYR-T4X34-R7VHC  - For WIN2K8 R2 standard Edition
  slmgr.vbs /ipk 489J6-VHDMP-X63PK-3K798-CPX3Y  - For WIN2K8 R2 Enterprise Edition
  slmgr.vbs /ipk TM24T-X9RMF-VWXK6-X8JC9-BFGM2  - For WIN2K8 Standard Edition
  slmg.vbsr /ipk YQGMW-MPWTJ-34KDK-48M3W-X4Q6V  - For WIN2K8 Enterprise Edition

Note : The above keys are Default Microsoft MAK keys. We should have KMS server in network, Otherwise it will not work.

2. After activating the KMS key, restart the Software Protection Service. 
3. Run “slmgr.vbs /ato” command
4. Wait for some time, check if OS license is activated, if not restart the server.

Second Method:

Manually targeting a KMS client to a KMS Host:

1. Open the command prompt in elevated prompt
2. Ping and check if the KMS server is reachable from client. KMS host should be reachable from client server.
3. Run the below command:
slmgr.vbs /skms  192.168.10.240:1688
slmgr.vbs /ato



Some other useful command:

slmgr.vbs /ckms - Enable Auto-discovery for a KMS Client

slmgr.vbs /upk  -To remove uninstall the current product key, run the following command and then restart your computer

slmgr.vbs /cpky -To remove License product key from registry.

slmgr.vbs /dli -To display very basic license and activation information about the current system

slmgr.vbs /dlv -To display more detailed license information–including the activation ID, installation ID, and other details



KMS vs MAK

Windows’ recent operating systems, particularly Windows Vista, Windows Server 2008, 2008 R2, Windows 7 and Office 2010 use an activation technology called Volume Activation which allows for activation automation that is transparent both to Volume Licensing customers and end users. Volume Activation can use either Key Management Service (KMS) model or Multiple Activation Key (MAK) model to activate the said systems. Customers can use both or either of the models. The main difference is in the type of key employed in the activation process. Add to that some practical considerations like organization type, network size, OS versions among others.
Activation with MAK is made possible by a unique alphanumeric key capable of activating a specific number of computers. As far as installation is concerned, KMS proves more convenient as it allows the computer to automatically detect it via DNS. A pre-requisite is a dynamic DNS with SRV record support. Without it, it may require manual and individual access to the clients’ registry to locate the local KMS. With met pre-requisites, no further client configuration for activation is required upon installation, even with newly-installed PCs, for as long as they are within the network.
MAK activation needs keen supervision during the installation and activation process. Every PC that is being added for activation is equal to individual configuration. However, MAK doesn’t need internet access to complete activation. Similarly, KMS is also capable of completion without further change on the firewall. Base requirement is for it to secure that the KMS host can connect to Microsoft’s volume licensing servers.
In terms of activation capacity and expiration, MAK is more advantageous than KMS. The former has a one-time, non-expiring activation. It doesn’t require frequent updates with product keys, thus better security from activation failure. The only downside would be its limited number of activation, wherein the quantity of clients that can be catered is dependent on the number of licenses purchased; thus, increasing the need to repurchase licenses over time. Conversely, KMS has to maintain two levels of reactivation every 6 months. First level comprises of every client within the network and second, the KMS host. This entails an extra task of regularly monitoring the KMS server, DNS, the clients and their connection status.
What’s good about it though is that it can activate an infinite number of clients regardless of license. Another important factor to consider is the organization’s IT structure (i.e. the number of computers, the type of machines ‘“ laptop or desktop, the number of sub-branches/ departments). KMS works best with more than 50 computers, mostly desktops, and with a centralized set-up. This is due to the fact that it is highly dependent to a KMS host. Even though a customer has the option to use several hosts, it is still ideal to maintain a single server; otherwise, it increases the risk on the integrity of the client-DNS-server connection, and not to mention, more maintenance and probable troubleshooting work. Unlike KMS, MAK works more flexibly even with less than 25 computers, both laptop and desktops, with decentralized IT structures. It poses not much limitation no matter how your IT infrastructure is organized- regardless if it has multiple branches, high security networks and uses a good mix of desktops and field computers.
Summary:
1. KMS requires activation but lets users do this within the network. Meanwhile, MAK entails one-time activation only.
2. To complete activation, MAK does not need internet connection. For KMS, you have to connect to Microsoft’s licensing servers.
3. MAK’s activation does not have to be renewed. For KMS, it has to be reactivated every six months.
4. KMS can even work very well with more than 50 computers. MAK can only function optimally with less than 25 computers.


How to Setup a Loopback Adapter


1.    Click the Start button. In the search box Type hdwwiz and then Click the hdwwize.exe program link. Or type “devmgmt.msc” in the “Run” and open “Add legacy hardware” from the action menu.



2. Now the Add Hardware wizard should be open.  Click Next through the first page, and then on the second Select Install the hardware that I manually select from a list (Advanced) Click Next to continue.



3. Scroll down the list and Select Network Adapters then Click Next.

4. Give the next window a moment to load, and then Click Microsoft and Select Microsoft Loopback Adapter then Click Next.



Now the Microsoft Loopback Adapter should be installed, and it will show up in your network connections window.  

Issue:

We may get “Access denied error” on a VMware Virtual Machine, while configuring a folder in IIS Manager or when you try to access a remote folder using any tool like Backup Exec, etc.

Resolution:
1.       Power off the VM and once powered off, right click the VM and click “Edit Settings”

2.       Under “Options” select “general” and configuration parameters.


3.       3. Select “Add Row” and in the name field enter “devices.hotplug” with the value “false”


Please see below the VMware KB article detailing the steps to disable to the VMware hot add functionality.




Mass export Tasks from Windows Task Scheduler:

Windows Task Scheduler holds all the tasks which was created by an application to periodically check for updates or by you to send an email when somebody logs in. Now if you want to create same type of tasks in another folder, Task Scheduler gives you an option to export them one by one and not all of them together.

The below steps helps you to export all the tasks in bulk.

All the Tasks created in Windows are stored in the Task Folder of Windows System Directory, for example, C:\Windows\System32\Tasks.

·         Navigate to Tasks Folder.

·         Here you will see a couple of folders with some files inside it. They represent the same folder structure of the Task Scheduler and files have same name too.


·         Now copy the task files to the machine you want to export to. You can also use it to backup your tasks in case your computer needs a re \installation, so you don’t have to create again.
·         Now rename the files with extension as .XML, this is the same extension used when you export the tasks using the Task Scheduler Interface.
·         Once renamed, now use the Task Scheduler Import task feature to import them one by one as Windows will not recognize them if you drop them directly into the Tasks Folder of Windows.