This is the outline of the process I use for Key Recovery in Active Directory Certificate Services. Variables are underlined to identify them. You should replace those variables with the corresponding values.

 Step #1 (optional): For a given certificate requester name, find all the certificates that have been archived and output their serial number.

*************************************************************************************************************************************************************************************************

certutil -view -restrict "Request.KeyRecoveryHashes=KRA HASH" -out "Request.RequesterName" | certutil -view -silent -restrict "Request.RequesterName=Requester Logon ID" -out "Serial Number"

ex: certutil -view -restrict "Request.KeyRecoveryHashes=e1 33 90 f0 7e 31 f0 50 44 30 0d b5 88 98 b5d4 69 bd 99 7a" -out "Request.RequesterName" | certutil -view -silent -restrict "Request.RequesterName=CONTOSO\KEYOWNER01" -out "Serial Number"

*************************************************************************************************************************************************************************************************

 Step#2: This command will take the serial number of the archived certificate (identified in step 1)  and dump it’s BLOB

 *************************************************************************************************************************************************************************************************

Certutil -getkey Certificate Serial Number Outputfilelocation

ex: Certutil -getkey 1111c230000000008989 C:\Extract\Blob

*************************************************************************************************************************************************************************************************

 Step#3:This command will take the blob file for the certificate you identified in step 1 and will extract the key in pfx format

 *************************************************************************************************************************************************************************************************

Certutil -f -recoverkey Blobfile user1key.pfx

ex: Certutil -f -recoverkey C:\Extract\Blob user1key.pfx

*************************************************************************************************************************************************************************************************

 Notes

In step 1, this is a piping process of two commands. The first one identifies all certificates that are encrypted and the second one identifies the certificates that belong to the user you specify

In step 3, you need to have the KRA certificate installed locally and you will be prompted to enter a password for the pfx file twice for confirmation

The answer turned out to be in auditing. When we configured the CAs for auditing, we configured it to log all events. A list of events is availabe here https://technet.microsoft.com/en-us/library/cc772451(v=ws.10).aspx

Configuring the CA to audit the event "Start and stop Active Directory Certificate Services (AD CS)" causes the delay in service start and stop. If your interest in fast startup time outweighs your interest in logging this event, you can either uncheck this event from the Audit tab of the CA properties, or if you're using a configuration script (CAConfig.bat), change the audit filter from 127 (audit all events) to 126  (audit all events but the service start/stop)

certutil -setreg CA\AuditFilter 127   certutil -setreg CA\AuditFilter 126

I hope this helps

The support team wrote this article to resolve this problem and it should work: https://support.microsoft.com/kb/933246

However, if it doesn't work for you, here's what the problem is. The tool is trying to write the boot files to the new system drive, but you might have applied an MBAM policy to prevent write-access to unecnrypted datadrives. With the data drives being unencrypted the system volume will be created but the tool will tell you that the drive is write protected This is due to the write-access prevention policy you created earlier for MBAM.

The resolution:

1- disable the GPO link that configured MBAM

2- restart the machine that you want to create the drive on

3- run the prep tool again

now it should work,

once it has worked, you can relink the MBAM GPO and run gpupdate /force

1. Install ADRMS in the resource forest
2. Use Forefront Identity Manager to migrate the user accounts from the user forest to the resource forest. The user accounts in the resource forest (called stub accounts) must be migrated as follows
1. Primary e-mail address must be migrated
2. The user SID must be migrated to the SID history attribute of the stub account https://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx
3. The msDS-SourceObjectDN  must be populated with the original DN of the user account
3. For users to be able to locate the SCP in the resource forest, the SCP must be created manually in the configuration partition of the user forest.
4. Disable SID filtering in the resource forest. (warning, before you perform this task, research the security implications of this action)
5. Any customizations to the registry (like ADRMS templates location, licensing servers etc) must be implemented in the user forest.

I hope this helps

1-      A time valid certificate and private keys needs to be available for encryption/decryption of data

2-      The client will only check for revocation status of the certificate, in the case of Encryption, or adding users to the EFS ACL. In the case of decryption or data access, revocation checking is not checked. Accordingly, revoking a certificate does not mean that the user has lost access to data; it only means that he/she cannot encrypt more files with it. The only way for it to become unusable is if it expires

Key Recovery Agent (KRA)

Key Recovery Agent is I would say the most systematic and controlled key fault tolerance method available. The reason for this, is that for key Recovery to occur the following conditions need to be fulfilled

1-      One or more users need to have a valid KRA certificate and private key

2-      Key archival needs to be enabled on the Issuing CA and on the Certificate template

3-      By default the Certificate manager needs to approve the issuance of the KRA certificate

4-      The CA manager(s) needs to manually extract a file from the CA Database that contains the intended private key using the command Cetutil –getkey

5-      The KRA need to take that file and decrypt it using his/her KRA private key

From an operational perspective, it is easy to apply governance to the KRA process especially if proper segregation of duties is applied. However, it is definitely the most time consuming method, and practically speaking, it might take the EFS Key owners too long to access files when they don’t have access to their private keys. The downside of KRA is that, data encrypted with old EFS keys cannot be recovered since they are not archived in the CA.

Data Recovery Agent (DRA)

The DRA is a shadow user that has access to EFS encrypted data, along with data owners and the designated users who have access to the data.

The issue with a DRA is that it is hard to govern the data recovery process. Practically speaking, if the DRA has access to the data location, he/she can access it maliciously. One way to govern DRA is use Forefront Identity Manager or to use smart card n to m authentication for the DRA user. The upside of DRA is that it provides the fastest recovery time.

Credential Roaming (CR)

Credential Roaming could be in a way looked at as a key fault tolerance option, because it allows for replicating the local key store from the user profile located on the computer to the user object on the ADDS. This is a good option and involves very fast key recovery time. However the downside of it is that it does not help when key deletion is intentional, since the local key store will replicate the deletion action. However in cases of hard disk failure or profile corruption (if the local profile is corrupted), there’s a big chance that they key on the user object will be retained since the deletion would most probably not be replicated.

Furthermore, this is a table that includes the roles that are supported for SYSPREP.  If you have to SYAPREP a machine that is intended to host a certian unsupported role, SYSPREP it before the role is installed.

I have shared it on SkyDrive, Download it here

Important I would like to append to this presentation, whatever you do, do not log on with high-privilege accounts (ex: domain admin) to an internet facing server. You could be vulnerable to your credentials hash being reused by an attacker, which is dangerous for high-privilege accounts.

Windows Server 2008 R2 with Hyper-V Role

Symptopms:

 VMs on a certain Hyper-V host were having bizzare connectivity patterns, when I tried to ping other machines, I would get three types of ICMP reponses for the same ICMP request. below is a snapshot

The network configuration is shown below, with the stable and the unstable communication paths

Resolution:

1- disable netDMA on the Host NIC (check this article https://support.microsoft.com/kb/951037)

2- Disable Large Send Offload on the Host NIC (in the advanced properties of the NIC)

What is possible though is migration. Migration involves exporting ISA’s configuration file, and importing into a TMG array/server. Below are the steps for performing the migration.

1-      Preparation Steps

a.       Make sure you export the web Certificates and the private keys on the ISA Server(if Any) to an external drive

b.      Make sure you jot down any custom routes that you have created

c.       Make sure Service Pack 1 is installed on the ISA server/array.

d.      If the ISA server is part of an array rather than a standalone server, disjoin one of the Array members from the array. (Make sure you don’t do this during business hours, unless you don’t like your job J). This server will be sued for the Exporting configuration.

e.      Setup a TMG Server, with the same network configuration as the disjoined ISA server

f.        Read the list of migration limitations https://technet.microsoft.com/en-us/library/dd897002.aspx

2-      On the disjoined server (or the standalone server), Open the ISA Server management console

3-      Right click on the server/array name.

4-      On the tasks panel on the right, select export server/array configuration

5-      On the first screen click Next

6-      On the second screen, you will be asked whether you want to include confidential information, and user permissions. If you want the TMG server to retain the same configuration, I suggest that you do export this information. This information would include things like saved credentials. This information will then need to be encrypted, using a password. Enter the password in the designated box.

7-      On the next screen, select where you want to save the XML configuration file. (It is one XML file)

8-      I you are migrating from an ISA Enterprise Edition to a TMG standalone array/server, run the tool EESingleServerConversionPack.exe against the XML file. You can find this tool on this link https://www.microsoft.com/downloads/en/details.aspx?FamilyID=8809CFDA-2EE1-4E67-B993-6F9A20E08607

9-      On the pre-prepared TMG server from step 1.e. Import the XML configuration file using the TMG Management Console

10-   Rename the TMG Server, to match the Disjoined ISA Server name. (If it is a domain member, delete the computer account of the old server, and join the TMG server to the domain using the same name)

11-   Add any custom routes and import any web certificates that you have exported from the original server/array.

12-   Add other TMG servers one by one, repeating what you did to the first server. Give the New array the same name of the ISA server array.

13-   Check the array/server status from the monitoring tab; make sure servers are in Sync’d.

14-   Setup TMG integrated Network load balancing on the TMG array (if applicable)

15-   Test your configuration again

TMG uses Its own Built-in Name resolution Cache, Then it fails back to DNS, then it fails back to Netbios Name Resolution. Accordingly below are some DNS related methods that can be used to optimize TMG Performance

1. TMG Perfroms Forward and backward name resolution for Firewall Rules, so pay attention to the effeciency of its access to the DNS server
2. DISABLE Netbios broadcasts on all network cards. Netbios resolution fails back to a broadcast which takes a very long time, leaving the request pending during that time. The best way to perform this is the following registry value
    Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT
    Parameters
    Name: NodeType
    Type: REG_DWORD
    Value: 2
3. It is preferable to dedicate a name Server for each TMG Server Array
4. Put the internal adapter on top of the adapters list, and configure it to use an internal DNS Server
5.  Do not configure Other adapters with DNS Servers