Windows 8 Media Center Free For a Limited Time

Though it doesn't seem to work yet, you can go here and get your key for Windows Media Center for Windows 8 Pro. I'm guessing it will go active tomorrow. I love WMC, and I'm guessing this will be Microsoft's last release of it; it seems they've chosen the Xbox as the go-forward media platform. Here's hoping some third parties can replicate the SmartGlass functionality for other devices with different software. :) Thanks for the heads up @GaborFari via @danielauger.

WSUS 3.0 vs. 2012/Windows 8 Notes

As I posted earlier, server 2012 includes a new version of WSUS. There are a few gotchas associated with WSUS and Server 2012/Windows 8, especially as it pertains to using a previous version of WSUS. Here are some key points:

• Windows 8 and Server 2012 "clients" will NOT work with WSUS 3.0 SP2 or any version that isn't shipped with 2012 unless this update is installed BEFORE any clients connect to it. 
• If your Win8/2012 clients attempted to talk to an older WSUS server before patching or upgrading, you will need to perform the following before they will update again: 
• Net stop wuauserv
• rd /s %windir%\softwaredistribution\
• Net start wuauserv
• If your new WSUS 2012 server is downstream from an older WSUS server, it will have the same effect as if your clients were pulling directly from that older server. All WSUS servers between the clients and MSFT need to be newer or patched. 
• According to Microsoft, updates canNOT be scanned by an intermediary... i.e. HTTPS inspection must be turned off on content from Windows Update. 

Client errors may manifest themselves as "error 0x80246003". According to the WSUS error table that corresponds to an unrecognized hash. I haven't completed my research yet but I'm guessing that the new endpoints will only honor update packages from MSFT using a new, stronger hash to raise security in the aftermath of the Flame malware. 

Sources:

Microsoft: WSUS SP2 Patch

Microsoft: Discussion on this topic

WSUS on 2012 Using SQL Install Note

Here's a quick tip that will hopefully save you some time:

As you may have noticed, WSUS can now be installed as a role service in Windows 2012. I'm using it successfully now with an "external" SQL server. If you plan on doing the same, note that when you install the role it will inform you that the Windows Internal Database feature is a prerequisite even though you don't intend on using it.

As you're going through install, feel free to un-check the Windows Internal Database feature. You'll get a chance to specify the SQL target during the configuration phase of the install and all should work right off the bat.

Unicast Network Load Balancing... Reliably

Microsoft Network Load Balancing can be difficult to setup reliably and there are a myriad of better options out there. With that enthusiastic endorsement, I'm writing this guide to walk you through (at a very high level) how to setup unicast clusters reliably.

Assumptions

• 2008r2 Servers (this should work down to 2k3 but there will be minor differences) 
• Both hosts are connected to the same switch or vSwitch
• You can have at least two NICs per host
• 1 static IP address per NIC. (i.e. 2 per host) 
• 1 IP for your clustered address
• You really want to do this and don't have a better way to split network traffic 

Example Network: 

In this example, we use the following addresses. Substitute in yours where applicable. 

• HostA: 192.168.1.5, (IP For Cluster NIC) 192.168.1.6 (IP for Other)
• HostB: 192.168.1.7, (IP For Cluster NIC) 192.168.1.8 (IP for Other)
• ClusterIP: 192.168.1.22

Steps

• Ensure each host has at least two NICs with the appropriate IPs configured. You *can* setup a unicast NLB cluster with one per host, but trust me you don't want to. (unless your app can't handle a multi-homed server)
• (Do for each host) Navigate to the advanced TCP/IP settings->DNS tab of the adapter that will participate in the cluster and UNcheck the box "Register this connection's addresses in DNS"
• Note: This will ensure that when the machine is looked up by its dedicated individual IP as opposed to the IP used by the cluster adapter which will share a MAC address with the other host. 
• Install the NLB feature. If you're not sure, here's some help: howto. 
• Open the NLB Manager Administrative Tool and right click the root->New Cluster
• Under Host, type the first host you wish to add, click connect, and then select the IP of the adapter that you removed from DNS a couple steps above and click "Next"
• Set the priority and default state. Priority is this host's priority in the cluster where a lower number represents a higher priority, and default state represents the participation of this host in the cluster. If you're not sure, take the defaults of 1 and Started. Click "Next"
• Click "Add" and put in your Cluster IP address. Click "Next"
• On the next "Cluster Parameters" screen, put in the DNS alias you will use for the cluster IP under "Full Internet Name" and set "Cluster operation mode" to "Unicast". Click "Next".

Cluster Params

• On the New Cluster: Port Rules you can accept the defaults unless you want to be explicit with your clustered ports. Click "Finish"
• Quick note: MS NLB doesn't support automatic failover based on service status, I.E. if the host is responding to any network requests it is assumed to be up even though the service may have failed. That's why I chose to accept the default and host all services on the cluster IP and dedicate a NIC to the task. This has proven to be substantially more reliable. For security, ensure your firewall is active and configured correctly. 
• Right click the newly created cluster and click "Add host to cluster" and input the second host. Follow the same steps that we did above for this host and exit the wizard. 
• If you're using VMWare: perform the steps under "Configuring Unicast Mode" listed in this document. This disables the automatic MAC relocation on the vSwitches. 
• If desired, do a static DNS registration for the "full internet name" of the cluster. 

That should do it. Remember that you will have to do fail-over manually in most circumstances. 

Sources/Additional Research: 

Microsoft: Tech Overview

Microsoft Forum: "Startup Warning"

Microsoft: NLB setup on 2k3 (Still relevant)

Microsoft: Selecting Multicast or Unicast

VMWare: Sample NLB Setup (good write-up)

VMWare: Microsoft NLB Multicast and Unicast Modes
VMWare: Implementing MS Network Load Balancing

Microsoft Clarifies TMG/Forefront Death Watch

As I'm sure you're aware, Microsoft recently announced the cancellation of Threat Management Gateway as well as Forefront Protection for Exchange & Sharepoint. This is disappointing news to many and I'm trying my best to avoid reading between the lines on this one.

That said, I found that on the fifth page of the comments the team posted a clarification post, which I'll quote here for reference:

Microsoft Server and Cloud Platform Team
  September 20th, 2012 2:32 PM

"We wanted to clarify some details around the discontinuation of Forefront TMG to help address many of the questions we’ve seen posted in the comments section.

First, it is important to note that while Forefront TMG is being discontinued, it will continue to be supported in mainstream support through April 14, 2015 and in extended support through April 14, 2020.  When and how a customer transitions to a replacement solution will depend on how the customer is using TMG today.  Customer use scenarios vary, but these general guidelines should help:

•  For customers using TMG for caching, secure web gateway (forward proxy), and firewall, we recommend that, prior to April 14, 2020, customers examine the many vendor solutions available in market today that offer comparable features to the TMG product.   Microsoft does not plan to transition this functionality to any other Microsoft products.

• For customers using TMG for reverse proxy, transitioning to Forefront UAG is an option.  Most web publishing scenarios that are supported by TMG can be published by UAG, though specific functionality may not be identical.   For customers who do not want to transition to Forefront UAG, customers should plan on transitioning to an alternative vendor solution prior to April 14, 2020.

•  For customers using Forefront TMG Web Protection Services, we recommend that customers examine the many vendor solutions available in market today that offer comparable reputation services by Dec. 31, 2015.  This product will no longer receive updates starting January 1, 2016.

We hope that these general guidelines provide additional clarity.  Please continue to contact your Microsoft account teams or partner managers with any questions about your specific scenarios.   

Regards,

The Forefront TMG Team"

HowTo: Run (Signed) Powershell Scripts as Scheduled Tasks with Minimal Rights

This is meant to be a straightforward howto: on the topic. While this sort of thing is quite common, I often times see people missing a few critical details that end up resulting in alot of unnecessary troubleshooting time. I will also cover steps needed to run signed scripts.

Assumes:

• Powershell 2.0
• Windows Server 2008 or R2 (will work on others but steps will be slightly different) 
• If signing script you know how to get a cert and basics about managing certs

Creating a signed script (optional) 

1. Ensure you have a valid code signing cert installed in your user store and that you're logged on as that user. This is easiest if your organization has PKI with a code signing template enabled. This user should NOT be the service account user, but rather the author of the script. (you I'm guessing)
2. After finishing your script, execute: 
1. $cert=@(Get-Childitem cert:\CurrentUser\My -codesigning)[0]  (assuming you have only one code signing cert) 
2. Set-AuthenticodeSignature .\myscriptname.ps1 $cert

Note: whenever you modify the script you'll need to re-sign it. 

Stage Server/Account 

1. Create the service account. To be controlled correctly this should be a domain account with no additional privileges above that of a standard user. For additional security, set it so the user can only log on to the computer you intend to run the script on. Use a  good password.
2. Give that user "Log on as a batch job" rights on the target server using the local security policy or group policy if applicable.
3. Create the directory the script will be stored in. Give the service account READ access to that directory.
4. Copy the script to the target directory
5. Variable step if signing or not:
1. If Signing: 
1. If signing execute as admin in powershell on the server: Set-ExecutionPolicy AllSigned
2. Log onto the server with the service account and run the script manually. This will prompt powershell to ask if you want to trust the publisher based on the cert. Select that you will always trust this publisher. (which is you!) If you can't log on locally or on a VM console you'll need to temporarily grant the service acct RDP access. 
2. If not signing, execute as admin: Set-ExecutionPolicy Unrestricted

 Setup Scheduled Task

1. Open Task Scheduler and navigate to the folder you would like the task to reside in. 
2. In the right plane, right click->Create New Task...
3. Give the Task a Name and Description. Don't skip the description, it'll save time having it there in the future. 
4. Select "Run whether user is logged on or not" and ensure the "Do not store password" box is NOT checked. Select "Run with highest privileges" ONLY if your script requires it. (Powershell itself does not) 
5. Click "Change User or Group" and enter the service account you created earlier. 
6. Select the "Triggers" tab and set triggers as appropriate
7. Select the "Actions" tab and click "New..."
8. Action: "Start a program"; Program/script: "powershell.exe" (full path shouldn't be necessary) ; Add arguments: "-NoLogo -NonInteractive -WindowStyle Hidden D:\path\to\your\script.ps1"
9. Change settings on the "Settings" tab if desired
10. Click "OK" and enter the password for the Service Account

That's it! If everything was done correctly it should run without problem. Depending on what the script does you may need to grant additional rights to filesystems, etc, but that's up to you to figure out since you wrote the script. :) I hope this post saved you some time getting your script up and running. 

No muss and/or fuss SQL DB Mirroring

So I've never really known what "muss" is, but this doesn't have any of that. It's sans muss. (without muss)

I must say that the SQL DB Mirroring error messages (at least as of 2008R2) leave something to be desired. Because of this, I figured I'd write a straightforward HOWTO on the topic. I've performed these steps on SQL 2008R2, but I suspect it will work on other versions as well.

This guide assumes the following:

• You have a DB on the Principal server that you wish to mirror
• That DB is NOT on the mirror target server (drop/delete it if so) 
• You do NOT intend on using a witness server.... using one however won't invalidate this guide, but we don't address the extra couple steps required to do so. 
• Your database is using a "Full" recovery model. (not possible otherwise) 
• You have sa access to both the Principal and Mirror server

Here are the steps, in order:

1. Log onto the Principal server
2. Perform a full backup to disk of the database in question. Ensure this is a new backup that doesn't include any previous backups.
3. Perform a tranlog only backup on the same database. While this step shouldn't be required, I've found that restoring a tranlog backup after the full results in a successful mirror pairing substantially more often. 
4. Copy the backup files to the Mirror server
5. On the Mirror server, perform a full restore of the desired database:
1. On the "General" page, ensure the "To database" is set to the exact same database name
2. On the "Options" page, select "Leave the database non-operational..." "RESTORE WITH NORECOVERY"
6. Right click the newly restored DB and select "Tasks"->"Restore"->"Transaction Log"
1. On the "General" page, select the appropriate file
2. On the "Options" page, select "Leave the database non-operational..." "RESTORE WITH NORECOVERY"
7. On the Principal server, select "Tasks"->"Mirror"
8. Click "Configure Security"
9. Select "No" for "Include Witness Server" and click "Next>"
10. Leave the ports default unless there is a reason to do otherwise. Make sure this port is properly opened on all firewalls (including the local firewall) between the to servers!
11. Select the target server, set the settings per your requirements (default are fine) and click "Next>". Double check that all firewalls are open on and between both servers. 
12. Enter the appropriate service account for this replication. While it is a lesser secure configuration, using the SQL instance domain service account (if you have one) works without issue. NOTE: If your SQL service instance is running as a local user, (including system) you must use certificate authentication which is NOT covered here.
13. Click "Next","Finish" then "Start Mirroring". All should work at this point. Note it is normal for the state on the Mirror server to be "Synchronized/Restoring".

Troubleshooting:
Explicitly grant connection rights to the "Mirroring" endpoint (note that's a name not a concept) to a given service account:
GRANT CONNECT ON ENDPOINT::Mirroring TO "Domain\Username"


Note that if you re-create the mirror it does not delete the endpoint. To delete the endpoint on each server: (assuming you took the default name of "Mirroring")
DROP ENDPOINT MIRRORING



References:
http://msdn.microsoft.com/en-us/library/ms189047(SQL.105).aspx
http://msdn.microsoft.com/en-us/library/ms189127.aspx

Good Luck!

Creating a Two Tier PKI With Windows 2008r2

I've recently undertaken the task of setting up a Public Key Infrastructure (offline Root, online issuer) for my current engagement. I've been through this a few times and there is a lot of info out there, so rather than write a detailed step-by-step, I'm going to list major notes & "gotchas" while providing links to other blogs and tech articles.

Update note: This article was authored in April of 2012, when SHA2xx adoption by network devices was such that SHA1 was still predominant in enterprises. When instructed below to use SHA1 for the online CA, please do not. SHA256 should be considered the minimum as of 2016.

Why an offline root? 

An offline root is a much more secure option than having your online issuing enterprise CA serve as root because if the root CA were to be compromised it could invalidate your entire PKI. By keeping your root CA offline (unplugged or shut down) you make it nearly impossible to compromise that box. In that scenario, if one of your online issuing CAs is compromised you will only need to revoke the certificates issued from that level down. (or just that CA depending on circumstances) This will save you from having to re-build from scratch.

More info: Technet Wiki entry by Kurt Hudson, Ed Price and others

Prerequisites:  

• Assumes there is no existing CA infrastructure. If you have one you will need to either A>Decommission or B> Transition. Follow the Decom link for more info there; the transition piece can have many variables so I won't cover that here.
• Assumes you have licenses for Windows. As of 2008, you will need at least 1 Standard edition (for the offline root) and 1 Enterprise edition. (for full functionality of the issuing CA, you can use Standard with slightly reduced functionality)

Step 1: Setup Offline CA

Setup Server

• Setup a new Windows 2008r2 Standard Edition server. If running on a virtualization platform err on the side of compatibility vs. performance when selecting virtual hardware. Make sure you record the admin password for your company since after getting the system setup it'll be quite a long time before you need to log on again.
• DO NOT JOIN THIS SERVER TO YOUR DOMAIN then fix your caps lock key. (mine was stuck) 
• Enable RDP if desired. (available under 3>Customize This Server in the "Initial Configuration Tasks") The rest of this guide assumes you're connected via RDP.
• Name the server as desired, then activate and then fully update using Windows Update. Make sure the time & time zone are set correctly. 

Install Certificate Services

• From Server Manager, select "Roles->Add Roles"
• On the Server Roles page, select "Active Directory Certificate Services" and hit "Next"
• Under "Role Services", select "Certification Authority" only & hit "Next". 
• The "Setup Type" should default to "Standalone"; ensure the "CA Type" defaults to "Root CA".
• On the "Private Key" step, select "Create a new private key" and then we have a couple choices to make under "Cryptography"
• CSP: Generally stick with the default "RSA#Microsoft Software Key Storage Provider" unless you have need of a different CSP by way of other network hardware such as smart cards, etc. You should know if you need a different CSP. If you don't, you don't. :)
• Hash Algorithm: This can be a bit tough; SHA256 (SHA2) is a much more secure hash than SHA1, but some systems may not be able to use it. (WinXP SP2, some Oracle services) You'll need to weigh the risk here. In my scenario I'm deploying this time around for a small/mid business with significant legacy equipment, so I'll favor compatibility over security. If you're unsure, follow my lead and select the "SHA1" algorithm. If you're certain you can get away with it, (not WinXP SP3 will have enroll issues) select "SHA256" or better.
• Key character length: This is a similar discussion as the hash. If you plan on having a key duration longer than 10 years, (which I'll recommend in a moment) it is generally suggested (2 links there) to shoot for 4096 bit, but that may have compatibility and performance tradeoffs. One notorious offender has been Cisco, but their main IOS resolved that issue in ver 12.4T. That said, ensure all devices you will need certs on and select for 4096 if possible. If you are unsure on not capable of verifying, select 2048.
• "Allow administrator interaction when the private key is accessed by the CA.": Check this if your CSP (above) requires it. The default Microsoft Software KSP does NOT require it.
• For "CA Name": Set a good common name for the root CA. This should not reflect the machine name but rather the organization, i.e. "MyCompany Root CA". Keep it short and without special characters. Set the Distinguished name suffix to something that doesn't reveal security information about your internal structure. This does not need to match AD as this isn't an AD integrated system. It can be blank if desired. I'm using "OU=PKI,O=CompanyName,C=US" where US is the country code. (use yours as appropriate)
• Validity Period: 20 years. A good rule of thumb is that top level CAs must be at least twice the duration of the CA directly below it. Do 10 if you like, but I see little reason for it. See here for further considerations.
• Certificate Database: Default locations for the offline root CA. We'll change the locations for performance reasons on the issuing CA but that's not a concern here.
• Accept the rest of the dialogs and continue. 

Step 2: Configure Offline CA

Change the Default Cert Request Action

First we'll ensure that certificate requests will NOT be automatically processed by the Root CA. Note: this appears to be correct by default in Win2k8r2, but due to its importance I'm leaving the step in.

• Open the cert authority and drill to Certification Authority->CA Name
• Right Click->Properties
• Policy Module->Properties
• Check the box that says "Set the certificate request status to pending."
• Click "OK" twice to get back to the main CA MMC

Set the CRL Publication Interval

The CRL defines which certificates have been revoked. You need to strike a balance between administrative overhead and time for effect on revocation. Since this CA is offline each time the CRL needs to be published it will be a manual process. The only certificate revocation that will be published by this is for a subordinate CA. For my scenario I'll be using the CRL publishing interval of 6 months.

• Expand your Root CA object and Right Click "Revoked Certificates"->Properties
• Set "CRL publication interval" to the desired time frame. I'm recommending 6 months.
• Ensure "Publish Delta CRLs" is not checked.
• Click "OK"

Set Configuration DN, Domain DN and Certificate Validity Period Registry Keys

Note: You can skip the ca\DSxxxxxxDN steps if you NEVER plan on publishing CRLs or Certs via Active Directory, but its an easy step so I don't recommend it.  

When you use variables in the AIA and CDP paths for the LDAP publication (i.e. ) these registry keys are referenced to populate those fields with the correct information. 

• Open a command prompt as administrator
• Execute "certutil -setreg ca\DSConfigDN CN=Configuration, DNpath" (i.e. certutil -setreg ca\DSConfigDN CN=Configuration,DC=CompanyName,DC=local)
• Execute "certutil -setreg ca\DSDomainDN DNpath"
• DNpath should be the appropriate path. To get it correct you can use ADSIEdit to connect to the default naming context. 
• Execute "certutil -setreg ca\ValidityPeriodUnits 10" 
• Execute "certutil -setreg ca\ValidityPeriod "Years"
• These last two commands set the default duration of certificates issued. Since we will only issue for intermediate CAs we'll set it for 10 years. If you set your RootCA for 10 rather than 20 earlier, follow your own lead and set this to 5 instead.
  

Set CDP and AIA Locations

The CDP and AIA locations specify the place clients can retrieve the CRL and certificate. Remember this CA is offline, so we need a maintainable future proof strategy to serve those up. For that reason, I'm recommending that the primary delivery method be http using a custom DNS name dedicated for the task. I'll then use our public web infrastructure (with split DNS) and rely on the SLA associated with that platform. I can then use host headers to parse out the PKI requests and have everything served up on port 80. I will be using the hostname pki.company.net. Substitute yours where appropriate. Alternatively it would be easy to use the custom DNS to point to your (not yet built) online issuing CA. Additionally we'll publish to LDAP as well. Note that the default paths will work for that since we set the registry locations, but I'll still be making some additional changes for added security. See here, here, and here for more info.

Note: After the changes below you may be prompted multiple times to restart the CA service. Don't do it then; we'll restart it all when we're done here.

• Select the CA name at the root and Right Click->Properties
• Select "Extensions" and ensure "CRL Distribution Point (CDP)" is selected
• Select "C:\Windows..." and ensure only "Publish CRLs to this location" is checked
• Select "ldap:///..." and click "Remove"  (IF you want added security...I'll explain why in a moment)
• Select "http://..." and click "Remove"
• Select "file://...." and click "Remove"
• Click "Add..." and type the following in "Location:" ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=01,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass> and click "OK".
• Important note: This is one place where I'm taking an extra measure of security; normally the CN=01 would be CN=(machinename), but I would prefer not to reveal the real name of the internal server in the CDP string. I'll be using a two digit incrementing integer for top level CAs and a three digit incrementing integer for CAs down the tree. Feel free to leave this to the default of machinename if you desire.
• With the new ldap:/// entry selected, ensure "Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually." and "Include in the CDP extension of issued certificates" are checked
• Click "Apply" 
• Click "Add..." and type the following in "Location:" http://pki.company.net/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl   (substitute the correct DNS name for your company)
• With the new http:// entry selected, ensure "Include in CRLs. Clients use this to find Delta CRL locations." and "Include in the CDP extension of issued certificates" are checked
• Click "Apply"
• Under "Select extension:" select "Authority Information Access (AIA)"
• If you chose to obscure the servername as listed a few points above: Select "C:\windows..." and click "Remove"
• Select "http://..." and click "Remove"
• Select "file://...." and click "Remove"
• If you chose to obscure the servername as listed a few points above: Click "Add..." and type the following in "Location:" C:\windows\system32\certsrv\CertEnroll\01_<CaName><CertificateName>.crt
• Click "Apply"
• Click "Add..." and type the following in "Location:" http://pki.company.net/CertEnroll/01_<CaName><CertificateName>.crt Substitute pki.company.net for you URL and if you did NOT opt to obscure the servername replace 001 with <ServerShortName>.
• With the new http:// entry selected, ensure "Include in the AIA extension of issued certificates" is checked
• Click "OK"
• When prompted to restart certificate services, select yes.

Notes: The default LDAP location for AIA should be fine provided you did the registry entry stuff above. The default C: and http:// locations are fine if you don't want to obscure the server names. At this point, double check all your entries. If you proceed from here and find out there was a typo in any one of these entries later you will have to revoke the issuing CA cert to re-mediate the problem.

Step 3: Setup Online CA

In this part of the exercise we'll install all the online CA features on one box. Depending on your environment you may want to split some of the services across multiple machines.  For scalability info, see: here.

Note, you may want to take a quick moment at this time to review Appendix A below regarding the role of the CAPolicy.inf file. 

Setup Server

• Setup a new Windows 2008r2 server. For full functionality on the issuing CA, use Enterprise edition. (Note 2012 has full functionality in standard and up) I recommend x64 for scalability reasons. If possible I'd recommend having a separate drive to house either the DB or the logs for performance reasons. (unless the drive is on the same subsystem) This server should be joined to the domain before you start installing certificate services.
• Enable RDP if desired. (available under 3>Customize This Server in the "Initial Configuration Tasks") The rest of this guide assumes you're connected via RDP.
• Name the server as desired, then activate and then fully update using Windows Update. Make sure the time & time zone are set correctly. 

Install Certificate Services

• From Server Manager, select "Roles->Add Roles"
• On the Server Roles page, select "Active Directory Certificate Services" and hit "Next"

Note: the next step will prompt you to add additional role services required by two of the main roles. When prompted, click "Add Required Role Services" to continue. 

• Under "Role Services", select "Certification Authority", "Certification Authority Web Enrollment","Online Responder" (if you plan on using OCSP, if you don't know what it is don't bother yet), and "Certificate Enrollment Policy Web Service" then click "Next". 
• Change "Setup Type" to "Enterprise" and click "Next".
• Change "CA Type" to "Subordinate CA" and click "Next".
• On the "Private Key" step, select "Create a new private key" and then we have a couple choices to make under "Cryptography"
• Refer to the info above for details about CSP, Hash, and Key Character Length. For my main issuing CA, which this will be, I will be selecting options to ensure compatibility. I would advise (at the time of this writing) against using 4096 bit for the issuing CA for performance reasons. 
• CSP: "RSA#Microsoft Software Key Storage Provider" (unless otherwise needed)
• Hash: "SHA1" (Unless you're brave enough for something nicer :) ) 
• Key Character Length: 2048
• "Allow administrator interaction when the private key is accessed by the CA.": Check this if your CSP (above) requires it. The default Microsoft Software KSP does NOT require it.
• For "CA Name": Set a good common name for the issuing CA. This should not reflect the machine name but rather the organization, i.e. "MyCompany Intermediate CA xx". (Where xx is an increment) Keep it short and without special characters. Set the Distinguished name suffix to the same as the root CA.
• Certificate Request: Select "Save a certificate request to file and manually send it later to a parent CA:" and save it locally to send over later. 
• Validity Period: 20 years. A good rule of thumb is that top level CAs must be at least twice the duration of the CA directly below it. Do 10 if you like, but I see little reason for it. See here for further considerations.
• Certificate Database: Optimally the database location and database log location should be placed on a disk other than the OS disk. (different disk, not just performance) If performance is a very large consideration (i.e. very, very heavy load) you can split the DB from the DB log location as well. I'll be placing both on D:. Create folders and place the certificate database location to D:\pki\CertServ and set the Certificate database log location to D:\pki\CertLog
• Authentication Type: Select "Windows Integrated Authentication"
• Note there may be situations one may want to use other methods, i.e. allowing requests originating from the internet. 
• Server Authentication Certificate: Unless you already have a certificate for this server, select "Choose and assign a certificate for SSL later"
• Web Server (IIS)->Role Services: Accept Defaults. The appropriate role services should already be selected, only add or remove if you have unique IIS needs. 
• Confirmation: Save the report if you like and then click "Install"
• Results: You will get a warning about the installation being incomplete since the Sub CA certificate needs to be processed. Save the report if desired and click "Close"  

Publish Root CA CRL & CRT to AD

• Fire up & login to the Root CA and then Open the Root CA Certificate Authority
• Expand the CA and right click on "Revoked Certificates"->"All Tasks"->"Publish"
• Keep "New CRL" selected and click "OK".
• Navigate to "C:\Windows\System32\certsrv\CartEnroll" 
• IF you changed the AIA location above to replace the machinename with 01 as I did, rename the .crt file so that the machinename portion of the file is replace with 01. I.E. servername_mycompany root ca.crt becomes 01_mycompany root ca.crt
• Copy the .crt and .crl files to a domain controller  (You will need to map a drive)
• Log onto the domain controller the files were copied to and open an elevated cmd prompt
• Navigate to where the files reside and publish the RootCA cert: certutil -dspublish -f "01_My Company Root CA.crt" RootCA
• Where: certutil is the tool, -dspublish is the action, -f creates a new container in AD, and RootCA specifies the cert is a Root CA cert. Important Note: For these certutil commands to run successfully you must be in the Enterprise Admin group.
• Publish the CRL: certutil -dspublish -f  "My Company Root CA.crl"

Publish Root Cert to Clients via GPO

• May as well do this while we're still on the DC: Open Group Policy Management & Right Click Default Domain Policy->Edit
• Drill to Computer Configuration->Policies->Windows Settings->Security Settings->Trusted Root Certification Authorities
• Right Click->Import->Next
• Select the Root Certificate->Next->Keep default of "Place all certificates in the following store"->Next->Finish
• Log off DC

Publish Root CA CRL & CRT to Web

This step depends entirely on what type of web infrastructure you plan on using, so I'll skip it with only the following advice: Make sure the CRL and the CRT are available from the CDP and AIA locations you advertised earlier. If using the split DNS approach test the retrieval from internal and external clients. Make sure you allow + signs on IIS7 or higher by allowing "double escaping" in Request Filtering.

Set Sub CA CDP and AIA

If you planned a good infrastructure for your Offline CA, you can leverage that here as well.

• Log on to Sub CA
• Select the CA name and Right Click->Properties
• Hit "OK" on the Active Directory Certificate Services warning. 
• Select "Extensions" and ensure "CRL Distribution Point (CDP)" is selected
• Select "C:\Windows..." and ensure "Publish CRLs to this location" and "Publish Delta CRLs to this location" are checked
• Select "ldap:///..." and click "Remove"  (IF you want added security...I'll explain why in a moment)
• Select "http://..." and click "Remove"
• Select "file://...." and click "Remove"
• Click "Add..." and type the following in "Location:" ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=001,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass> and click "OK".
• Note: This is another place where I'm taking an extra measure of security; normally the CN=001 would be CN=(machinename), but I would prefer not to reveal the real name of the internal server in the CDP string. Since this is a sub CA I'm using a three digit incrementing integer. Feel free to leave this to the default of machinename if you desire.
• With the new ldap:/// entry selected, ensure "Publish CRLs to this location","Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually.", "Include in CRLs. Clients use this to find Delta CRL locations","Include in the CDP extension of issued certificates", and "Publish Delta CRLs to this location" are checked
• Click "Apply" 
• Click "Add..." and type the following in "Location:" http://pki.company.net/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl   (substitute the correct DNS name for your company)
• With the new http:// entry selected, ensure "Include in CRLs. Clients use this to find Delta CRL locations." and "Include in the CDP extension of issued certificates" are checked
• Click "Apply"
• Under "Select extension:" select "Authority Information Access (AIA)"
• If you chose to obscure the servername as listed a few points above: Select "C:\windows..." and click "Remove"
• Select "http://..." and click "Remove"
• Select "file://...." and click "Remove"
• If you chose to obscure the servername as listed a few points above: Click "Add..." and type the following in "Location:"C:\windows\system32\certsrv\CertEnroll\001_<CaName><CertificateName>.crt
• Click "Apply"
• Click "Add..." and type the following in "Location:" http://pki.company.net/CertEnroll/001_<CaName><CertificateName>.crt Substitute pki.company.net for you URL and if you did NOT opt to obscure the servername replace 001 with <ServerShortName>.
• With the new http:// entry selected, ensure "Include in the AIA extension of issued certificates" is checked
• Click "OK"

Process and Install Sub CA Certificate

• Log onto Sub CA
• Copy the previously created certificate request from the root of C:\ to the Offline CA
• Log onto the Offline CA and Open the Certificate Authority 
• Right Click the Root of the CA->"All Tasks"->"Submit New Request"->Select the request you just copied over
• Click "Pending Requests"->Right Click (should be ID2)->"All Tasks"->"Issue"
• Click "Issued Certificates"->Right Click (should be ID2)->"Export Binary Data"
• Keep "Binary Certificate" selected and choose "Save binary data" & click "OK"
• Save as "cert.p7b" locally and then move it to the Sub CA
• Back on the Sub CA: Right click the root of the CA->"All Tasks"->"Install CA Certificate" & Select the p7b from the Root CA
• Start the CA with the "Play" button at the top. 
• Make sure you delete the requests and generated certificates (*.req and *.p7b)  from the filesystem on all servers.
• If you chose to obscure the servername as listed a few points above: You may need to manually add the CRL to AD for the first publish due to a bug; Open a CMD window as administrator and execute certutil -dspublish -f  C:\windows\system32\certsrv\certenroll\CRLFileName.crl

Publish Sub CA CRL & CRT to Web

If you used the built-in web server you don't have much to worry about here, but if you, like I did, utilized your external facing web farm to leverage split DNS and that SLA, you'll need to devise a way to publish the CRL (and delta) regularly to the web farm. Since that shouldn't be part of the same domain you may need to get creative. I'm thinking about creating a dedicated service account, giving it an EFS cert, and then storing the powershell script on the server with the username/password required in there. That way only the svc acct will be able to read the script. I won't outline that now though... perhaps in a future post.

Test AIA and CDP Points With an Issued Certificate

With the first issued cert from your Sub CA, drop to a command line as administrator and execute: certutil -verify -urlfetch certname.cer . This will display the result of checking the AIA and CDP of both the root and the Sub. If there are any problems go back and clear them up now before issuing any more certs. If there is an issue with the root you'll have to fix it and re-issue the Sub CA cert.

When you're done, take the issuing CA Offline.

Step 4: Template Configuration, etc.  

At this point you're actually done with the setup, but it's not all that functional yet. The next section is a start on getting the system to actively issue certificates. Before proceeding in these steps it is recommended that you mess around a bit to familiarize yourself with the product. The examples below are only a few of what could and should be many different certificate templates for a fully featured PKI. Please take time to understand certificate templates before calling it completed and firing up your infrastructure.

Important Note:  Throughout this next step I will make a couple references to enabling auto-enrollment security permissions on a given certificate template. While this is what we will ultimately want, I recommend that you first enable enroll only, test the template with a manual enrollment & use, and then circle back and enable auto-enrollment after you have verified proper functionality.

Make Desired Certificate Template Modifications

Before opening the floodgates for certificate auto-enrollment, you will want to modify certificate templates as desired. Cert templates control everything from cert duration to cert purpose. There are some that are installed by default, but I'd highly recommend familiarizing yourself with the concepts and making necessary changes before certificates are issued. Here are some great links to get you there:

• Microsoft Technet: Planning Considerations
• Chris @ Technet blog (awesome!)
• Technet Certificate Template Troubleshooting
• Technet: Key Archival and Recovery

At a minimum I would configure user and EFS templates for key archival. For more information regarding Key Recovery Agents, see "Identify a Key Recovery Agent" at Technet. As a demonstration, let's setup Key Archival and fix up the basicEFS template:

Key Recovery Agent Setup

First, we need to select an account for the KRA:

• Create or select a user that will act as the Key Recovery Agent. Choose wisely and document accordingly; this acct will need be around for awhile. I created a separate account for just this purpose.

Now, let's modify the Key Recovery Agent template:

• On the issuing CA, Right Click "Certificate Templates" and click Manage
• Right click "Key Recovery Agent" and click "Duplicate"
• Select Windows 2003. This will make the template V2... if we don't need V3 functionality don't create it. 
• Under "General" change the Template Display Name to Key Recovery Agent for CompanyName; I like to append the company name to the default name so you know on what it is based and who it's for. Leave the Template Name as is. (it will auto change)
• Under "Request Handling" ensure that "Allow private key to be exported" is checked. This will allow us to export the key and save it somewhere safe. 
• Under "Superseded Templates" click "Add...", select "Key Recovery Agent" and click "OK".
• Under "Security" add the account you chose earlier and give it "Read" and "Enroll" rights.
• Click "OK"
• Start the CA server (Temporarily to for these tasks) 
• Back on the CA, under "Certificate Templates", right click in a blank space on the middle plane and select "New"->"Certificate Template To Issue"
• Select your new EFS certificate template and click "OK"
• Repeat the last two steps for your new Key Recovery Agent. 
• Select "Basic EFS" and press delete; click "Yes" to confirm 

 Now let's get a key for the KRA. The easiest way I know of to do this is as follows:

• Open an administrative Command Prompt
• Execute "runas /user:domain\kraAccount mmc" then hit Enter and type the password. Substitute the domain and kraAccount with the right account info. 
• Add the certificates snap-in (personal) to the MMC and click "OK"
  
• Right click on "Certificates (Current User)"->"Personal"->"All Tasks"->"Request New Certificate"
• Click Next
• You should see "Active Directory Enrollment Policy" under "Configured by your administrator". Select it and click "Next". 
• Select "Key Recovery Agent for MultiTech" and click "Enroll"
• After that completes, go back to your Issuing CA and look under "Pending Requests"
• Right click the pending cert and approve
• Navigate to "Issued Certificates"
• Right click the newly issued KRA cert and Right Click->"All Tasks"->"Export Binary Data"
• Select "Save binary data to a file" and save the cert (as whatever.p7b) to somewhere you can get to with the client.
• Back at the client, Right click "Personal"->"All Tasks"->"Import" 
• When prompted, select your new cert and navigate through the wizard. 
• After importing, select the newly imported cert (under personal->certificates) and Right Click->"All Tasks"->"Export"
• Hit "Next", "Yes, Export the Private Key", "Next", "Personal Information Exchange...","Next", type a password, "Next", select a location, "Next","Finish"
• Copy that key to a safe location that will be backed up. 

Enable the Recovery Agent on the Issuing CA

• On the Issuing CA, right click the CA name and click "Properties"
• Hit the "Recovery Agents" tab and select "Archive the key"
• Click "Add" and hit "OK" when presented with the cert you just created.
• Click "OK"
• Restart the service when prompted.
  

Modify the Basic EFS Template 

• On the issuing CA, Right Click "Certificate Templates" and click Manage
• Right click "Basic EFS" and click "Duplicate"
• Select Windows 2003. This will make the template V2... if we don't need V3 functionality don't create it. 
• Under "General" change the Template Display Name to Basic EFS for CompanyName; I like to append the company name to the default name so you know on what it is based and who it's for. Leave the Template Name as is. (it will auto change) 
• Check "Do not automatically re-enroll if a duplicate certificate exists in Active Directory". Publish in Active Directory should already be checked. This will ensure if a user already has pulled an EFS cert and stored it in AD that the old one will be used rather than grabbing a new one.
• Under "Request Handling" check "Archive subject's encryption private key". This will store a copy of the private key on the CA so that you can use the key recovery agent to get it in the future if it is a problem.
• Under "Superseded Templates" click "Add...", select "Basic EFS" and click "OK". This will force people who pulled an EFS template to get a new cert with this one.
• Under "Security" check "Autoenroll" for "Domain Admins", "Enterprise Admins", and "Domain Users" and/or anyone you would want to use EFS. (Important, see the note below)
• Click "OK"
• Start the CA server (Temporarily to import cert) 
• Back on the CA, under "Certificate Templates", right click in a blank space on the middle plane and select "New"->"Certificate Template To Issue"
• Select your new EFS certificate template and click "OK"
• Select "Basic EFS" and press delete; click "Yes" to confirm 
• Stop your CA to prevent issuing more certs before you have completed your template tweaks

Note: Unless you fully understand EFS, don't go forward without revoking the permissions to "Domain Users" on the template. If you have users who have files already encrypted with local or other PKI keys you'll need a migration strategy. It may be worthwhile to initially set the template to "enroll" rather than "autoenroll" and then use "cipher.exe /K" to gen a new key, "cipher.exe /U" to update previous files, and then "cipher.exe /x" to export the key for other machines. (remember the private key is not stored in Active Directory) For more info, see: 

• here
• here
• here
• here 
• here
• here 
• here
• here 
• and here

Zow, that was fun. So much so I'll do another one. The default DC cert is the Windows 2000 geared "Domain Controller". If you, like I, have all 2008 or higher DCs you can use the "Kerberos Authentication" template. If you have mixed 2003/2008 or just 2003 use the "Domain Controller Authentication" template.

• On the issuing CA, Right Click "Certificate Templates" and click Manage
• Right click "Kerberos Authentication" and click "Duplicate"
• Select Windows 2003. This will make the template V2... if we don't need V3 functionality don't create it. 
• Under "General" change the Template Display Name to Kerberos Authentication for CompanyName; Leave the Template Name as is.
• Under "Superseded Templates" click "Add...", select "Domain Controller" and click "OK". Rinse and repeat for "Domain Controller Authentication" 
• Click "OK"
• Start the CA server (Temporarily to import cert) 
• Back on the CA, under "Certificate Templates", right click in a blank space on the middle plane and select "New"->"Certificate Template To Issue"
• Select your new Kerberos certificate template and click "OK"
• Select "Domain Controller" and press delete; click "Yes" to confirm  
• Select "Domain Controller Authentication" and press delete; click "Yes" to confirm  (Unless you have 2k3 DCs)

To get SSL encrypted LDAP working, follow the instructions in this article.

Let's make one for Terminal Services & Standard Machine ID/Encryption:

Note: Let me save you some time & research and just state that you cannot automatically add the NETBIOS name as a subject alternative name with templates. If you want so suppress the certificate warnings on RDP connections you'll need to use the FQDN.

• On the issuing CA, Right Click "Certificate Templates" and click Manage
• Right click "Computer" and click "Duplicate"
• Select Windows 2003. This will make the template V2... if we don't need V3 functionality don't create it. 
• Under "General" change the Template Display Name to ComputerForCompanyName; Leave the Template Name as is.
• Note: Per several articles, Microsoft dictates that: "Important: You must set the certificate template’s attributes Template display name and Template name to the same value."  Because of this, I've omitted all spaces from the Computer certificate in this demonstration. 
• Under "Superseded Templates" click "Add...", select "Computer" and click "OK".  
• Under "Security" check "Enroll" and "Autoenroll" for any Machines you want to autoenroll. You will have to add the specific machines/groups if need be.
  
• Click "OK"
• Start the CA server (Temporarily to import cert) 
• Back on the CA, under "Certificate Templates", right click in a blank space on the middle plane and select "New"->"Certificate Template To Issue"
• Select your new Computer certificate template and click "OK"
• Select "Computer" and press delete; click "Yes" to confirm

Edit GPO to Specify Certificate Template

At the desired level (be it Default Domain Policy or a policy that applies to servers only, etc.) edit the target GPO. This procedure will automatically set templates for Windows Vista and higher machines. For 2k3 & XP you'll need to open the certificates MMC and request a cert manually. Fortunately they will detect the issuing CA and process the request from template quickly.

• Navigate to "Computer Configuration"->"Administrative Templates"->"Windows Components"->"Remote Desktop Services"->"Remote Desktop Session Host"->"Security"
• Edit "Server Authentication Certificate Template" 
• Enable the setting and type the template name (ComputerForCompanyName)
• Click "OK" and close the GPO Object

Configure Default Domain Policy for Auto-enrollment

• Open group policy management and edit the "Default Domain Policy"
• Navigate to "Computer Configuration"->"Windows Settings"->"Security Settings"->"Public Key Policies" and modify "Certificate Services Client - Auto-Enrollment Properties"
• Set "Configuration Model" to "Enabled" and check "Renew expired certificates..." and "Update certificates that use certificate template" and click "OK"
• Navigate to "User Configuration"->"Windows Settings"->"Security Settings"->"Public Key Policies" and modify "Certificate Services Client - Auto-Enrollment Properties"
• Set "Configuration Model" to "Enabled" and check "Renew expired certificates..." and "Update certificates that use certificate template". Enable "Expiration Notification" if you like and click "OK"

Now double check everything. If all elements look to be configured correctly feel free to start up the issuing CA and watch the requests come in.

Congrats! You have setup an enterprise class Certificate Authority, one of the most crucial security components of any enterprise infrastructure. You probably deserve a caffeinated beverage now.

Appendix A: When to use a CAPolicy.inf file  

Note: See Windows 2008r2 CAPolicy.inf syntax for implementation specifics

The %systemroot%\CAPolicy.inf file can be put into place on a target CA to further customize the creation of the certificate associated with that CA and SubCAs. If you do wish to customize the Root CA cert with any of the values listed below you'll need to do so prior to the creation of the CA cert; you can't add this stuff after the fact without re-issuing impacted certs.

In Windows 2003, it was necessary to always use a CAPolicy.inf file to ensure the root didn't have a CDP or AID associated with its cert, but that was fixed in Windows 2008. Due to this, it's no longer required to use the CAPolicy.inf file for a proper implementation, but there are some points where you may still want one. Here are the major ones:


PolicyStatementExtension: Use this to issue a legal notice, link to your use policy, or (if you need to) specify an OID. (You'll know if you do, generally applicable for external facing CAs issuing certs to third parties) Important note, if you plan on using certificate templates with issuance policies, you should take a look at this reported issue and follow the advice there. The easiest one of his steps to implement at PKI hierarchy creation time is #2. I'll copy his logic here in case the link goes bad:  (OID 2.5.29.32.0 is shared among all MS PKI deployments)

[Version]
Signature= “$Windows NT$”
[PolicyStatementExtension]
Policies = AllIssuancePolicy
Critical = FALSE
[AllIssuancePolicy]
OID = 2.5.29.32.0

CRLDistributionPoint: This is only applicable for the RootCA and shouldn't be used in most cases. Most platforms don't honor CRLs for a root CA anyhow. Doing so would question the concept of a trusted root.

AuthorityInformationAccess: Same as above; you would only have the AIA if you already have the cert, and if you already have the root cert you either do or don't trust it already.

EnhanceKeyUsageExtension: Use this to limit the usage of this CA cert (or otherwise) to specific uses. If omitted, the CA can be used to issue any type of cert. Obviously you'll leave this blank in most scenarios.

BasicConstraintsExtension: If you are relatively certain of your long term hierarchy you may want to use this on the root CA to limit how many SubCAs may fall under this root CA. If set to 1 for example it would make it impossible for a SubCA to issue a cert for a lower level SubCA. If you desire to implement this on a SubCA but not the root, configure the registry rather than using the CAPolicy.inf.

CrossCertificateDistributionPoints: Use to specify a CCDP location (URL) if your CA has been certified by a third party PKI. You may also specify the SyncDeltaTime (how often the URL is updated) here if desired. This value will only be used when you have negotiated a cross-PKI certification. Obviously you would know if you've done this. :)

RequestAttribues: Generally used on a SubCA; this allows you to change the default SubCA template that will be used. To use this value you will need to have duplicated the Sub CA template to a new name, apply the changes you desire, publish the template, and set the CertificateTemplate value to your duplicated template. The default template is version 1, so if you would like a version 2 or 3 certificate for your SubCA you'll need to use this field.

certsrv_server: Control the renewal settings for issuing CA certs. Usually not used because 1> The defaults are sufficient for most and 2> They can be changed "on the fly" (with services restart) in the registry on CAs for all certs issued thereafter. You may want to take a look at setting LoadDefautTemplates to 0 if you want to ensure your CA doesn't issue any certs until you publish your custom templates. You will see it recommended in some places to explicitly set the renewal validity here even if you do use the defaults, but I opt not to. Though it may be spelled out directly in this text file, I'm more a proponent of handing off the "Tyranny of the Default" (thanks Steve Gibson) to anyone down the line. Generally this will ease troubleshooting because assumptions of the default are true. I.E. only change it if the default values will not work for you.

Now to address the oft-asked question "Do I need a CAPolicy file?" directly: Can you get by without a CAPolicy.inf in Windows 2008r2? Yes. Should you? Only after you review and understand its role in the process can you safely ignore it. More often than not you will want to use it to tweak a setting or two.

More references for CAPolicy.inf:
Designing and Implementing a PKI Part 2
Windows Server 2008r2 CAPolicy.inf Syntax
MS Social: CAPolicy.inf questions
CAPolicy.inf syntax

Appendix B: Publish new CRLs from Offline CA

Every six months (in our implementation) you will need to publish the new certificate revocation list to keep everything running smoothly. To do so:

• Fire up the offline Root CA & login as admin
• Open & expand CA object in the CA management MMC
• Right click "Revoked Certificates"->"All Tasks"->"Publish"
• Navigate to "C:\Windows\System32\certsrv\CertEnroll"
• The new CRL should be there; now you need to copy it to the appropriate path on the webserver and publish to AD. Copying to the webserver speaks for itself, AD info follows:
• Copy the file to a domain joined computer & log on to that box with Domain Admin privs
• Open a command prompt as administrator  
• Execute the command:  certutil -dspublish "My Company Root CA.crl"
• Done! Log off the PC and shut down the Offline CA for another six months.

Questions/Comments/Improvements please let me know. Thanks and good luck!

0 to DC in 60 Minutes: Virtual Windows 2k8r2 Core as DC in existing Domain

Let's build a Server Core 2k8r2 machine on VMWare ESXi 4.1 and join it to an existing domain. This should be fun. This guide assumes you have already prepared the domain for 2k8 DCs. If you need help there, see this great blog. The moral of the story is that you need to perform adprep.exe /forestprep on the schema master, /domainprep and /domainprep /gpprep on the infrastructure master, and /rodcprep on the domain naming master.

We'll build it from scratch; no image. First, lets' configure the VMWare machine.

VMWare Settings

Unless noted, settings are default. (i.e. if a component is omitted it's default) 

Memory: 4096GB

CPUs: 2

SCSI Controller 0: LSI Logic SAS (Paravirtual would require a driver disk for setup)

Network Adapter: Proper VLAN, Paravirtual or E1000. I generally use E1000 for domain controllers. 

Hard Disk 0: 40GB for core

Hard Disk 1: (optional) 20GB for logs, 3rd party apps if necessary

Mount your Win2k8r2 ISO on the CD/DVD drive and make sure it's Connected/Connected at Power on. Start the VM. 

Installing Winders

Note: Select x64 or x86 as you prefer. Feel free to add a x64 machine in with DCs that are only x86. 

When navigating through the installer select the correct version. In this exercise I'll be selecting "Windows Server 2008 R2 Standard (Server Core Installation)". If prompted for the type of installation, select "Custom (advanced)". Select Disk 0 as the install target. The install should go quick, and the first thing you'll be prompted to do is select an Administrator password. Use "password" and never change it. (Hah Hah! You see what I did there?) 

Using the console, log on to our new server as administrator and then we'll go point by point; unless noted otherwise commands are assumed to be executed from a command prompt on the target server. 

Configuration

Install VMWare tools (or HyperV if you desire) 

• Mount the CD: (Right Click VM->Guest->Install VMWare Tools)
• Assuming D:  msiexec.exe /i "D:\Vmware Tools.msi" /qn
• The server will automatically reboot after installation; log back on after it comes up. 

Set IP Addressing information

• netsh int ipv4 set address name="Local Area Connection" static 192.168.11.99 255.255.255.0 192.168.11.254
• Where: "Local Area Connection" is the name of the connection, "static" defines the IP as static, "192.168.11.99" defines the IP, "255.255.255.0" defines the mask, and "192.168.11.254" represents the default gateway
• netsh int ipv4 add dnsserver "Local Area Connection" 192.168.11.103 index=1
• netsh int ipv4 add dnsserver "Local Area Connection" 192.168.11.100 index=2 
• Where: "Local Area Connection" is the name of the connection, "192.168.11.103" represents the IP of the DNS server, and "index=1" is the priority of the server

Rename the computer and join it to the domain

• netdom renamecomputer %computername% /newname:COMPUTERNAME
• Where: "renamecomputer" is the command we're issuing, "%computername%" is the necessary part of the argument that specifies the current name of the computer, (feel free to use the variable, it'll work) and "/newname:COMPUTERNAME" is the new computer name. Replace with your naming standard. For enterprise scalability I recommend naming your servers after your neighbor's kids. 
• shutdown /r /t 0 
• This will shutdown and restart the computer; "t 0" specifies wait for 0 seconds. After the reboot you'll still need to use the VMWare/HyperV console because we haven't opened RDP ports yet. 
• netdom join %computername% /Domain:DOMAINNAME /UserD:username /PasswordD:password
• Where: This command joins the computer to the domain. Specify the NETBIOS domain name (a couple configs may need the DNS Name) and a username/pass that can add machines to the domain. Note that the extra D after user and password is NOT a typo. 
• shutdown /r /t 0

Enable RDP and open appropriate Firewall holes

• Cscript %windir%\system32\SCRegEdit.wsf /ar 0
• Enables RDP
• netsh advfirewall firewall set rule group="Remote Desktop" new enable=yes
• Allows RDP through firewall 
• netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
• Allows "Manage This Computer" functionality remotely
• netsh advfirewall firewall set rule group="Remote Event Log Management" new enable=yes
• Allows browsing through Event Logs remotely

Configure Disks: (Optional)  In my example I'm assigning the virtual CD/DVD-Rom to J: and then creating a partition for my second disk, formatting it, and setting it to D:

• diskpart
• list volume
• Volumes will be listed. You need to find the DVD-Rom, which will list its Fs type as "UDF". In my case it's volume 0, but I'll refer to it in the next example as "X"
• select volume X
• Use the correct volume number. 
• assign letter=X
• We put our server standard to J to keep it away from common HDD letters. 
• list disk
• now we will look for the disk # representing the secondary disk; it should be the disk with the size and free space reporting the same size. In my case it's Disk 1, but I'll use X in the command
• select disk X
• Use the correct disk number for X
• create partition primary
• Creates a "standard" partition
• assign letter=D
• Replace "D" with whatever drive letter you want
• select partition 1
• Select the partition we just creatd
• format fs=ntfs label="Data" QUICK
• Format the volume, replace the label with whatever you desire; QUICK is a quick format

Activate the Server (important to do before we bring it into the domain)

• slmgr.vbs -ato
• If you receive an error, you may have used the wrong ISO and you'll have to switch the product key. To do so, contact MSFT, get the new key, then do: 
• slmgr.vbs -ipk PRODUCT KEY HERE
• slmgr.vbs -ato 

Update the Server

• Use the sconfig tool or this method to fully update the server prior to install.

Create the Unattended Answer File for DCPromo

If you don't have an unattended answer file from an earlier DCPromo (which is likely or you probably wouldn't be here) you will have to create one from scratch. This isn't so tough as it would seem. The guidelines for the unattended answer file can be found here. Feel free to use mine as a starting point; here is my final file with the appropriate information obfuscated. Note that my example changes the default locations for the Database Path, LogPath, and SYSVOL path. This is not necessary and if those lines are omitted they will be installed to the default locations. Also note that if you're not adding this DC to an existing domain but rather creating a new one, this file should be quite different. 

[DCINSTALL] 

UserName=userName

UserDomain=NETBIOSDomainName

Password=passwordHere

SiteName=Site-Name-Here

ReplicaOrNewDomain=replica

DatabasePath="D:\NTDS" 

LogPath="D:\NTDS" 

SYSVOLPath="D:\SYSVOL" 

InstallDNS=yes

ConfirmGC=yes

SafeModeAdminPassword=passwordHere

ReplicaDomainDNSName=FQDomainName.lan

RebootOnCompletion=no

After you have completed the creation of your unattended answer file, place it in a temp folder on the target machine. For the purposes of this guide, we will assume \\ComputerName\c$\temp\dcpromo.txt

Promote the Machine to a Domain Controller

• dcpromo.exe /answer:c:\temp\dcpromo.txt
• Remember that we're assuming c:\temp\dcpromo.txt for where the unattended file was placed; if you don't 
• If all is successful towards the end you should see "Active Directory Domain Services is now installed on this computer for the domain "domain.name.here"
• shutdown /r /t 0

 Test the new DC

• dcdiag /c /v /f:c:\temp\dcdiag.txt
• This performs all DC Diagnostic tests (/c) and logs verbosely (/v) to c:\temp\dcdiag.txt . If you're not confident troubleshooting this output add an /i to the command line after /c, which will suppress unimportant error messages.
• After running, review the log for errors. It is normal to see a couple warning messages from the File Replication Service right around the time of the DC promotion.

That's it, you're done! Feel free to comment or e-mail with questions or comments.

Update 5/20/2013: I wanted to note that I've successfully used this methodology for Windows 2012 core as well, despite dcpromo being deprecated. The only change to note since the article was written is to ensure you use e1000e (or VMXNet3) rather than e1000 if you're using a VMWare VM.

Enabling SPDY Protocol in Firefox!

Google services seem slower on FF than on Chrome?

The recently released Firefox 11 supports the SPDY protocol. Google services use SPDY if negotiated & Chrome has had it enabled by default for some time. Let's enable it on Firefox: 

• Open a new tab in Firefox and navigate to about:config (no http:// or anything)
• Click "I'll be careful, I promise!"
• In the search box, type "spdy". 
• Double-Click "network.http.spdy.enabled" to toggle it to user set - boolean - true
• Restart the browser

That will do it! For more info about SPDY check out this great podcast: Security Now! With Steve Gibson and Leo Laporte Episode 343.

Edit: note that this change is per-user, not system wide.
Edit2: A new addon that reports if the site was pulled via SPDY with an address bar indicator!

Complete IT Systems Overhaul Nearly Complete

I've just finished the initial phase of a complete systems overhaul for my current employer. We've virtualized the vast majority of the servers, re-engineered the network and replaced nearly every switch, installed new firewalls and built the rules from scratch, setup a centrally managed & secured wifi infrastructure, provisioned a new SAN, and much more. I've been fortunate enough to work with brand new Cisco, VMware, EMC, HP, Redhat, Veeam, Symantec, Microsoft products. I intend on posting lessons learned here along with how-to articles for some very interesting tech. Stay tuned!

Trunking an Extreme 450a to a Cisco 3750 via LACP

I've seen several attempts of this elsewhere on the 'net but most had a few errors that caused issues. Here's the approach that worked for me:

Extreme side: Assuming ports being assigned are not untagged on any VLANs or in use by anything else

Assuming port 5,6,7,8:

Enable sharing 5 grouping 5,6,7,8 lacp

Add to VLANS we need to route:

configure VLANname1 add ports 5 tagged

configure VLANname2 add ports 5 tagged

Cisco commands:

Assuming 2x core switches chained, ports 37 and 38 each. 

interface range g1/0/37-38,g2/0/37-38

description temp connection to extreme core

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 48 mode active

interface port-channel48

description temp connection to extreme core

switchport trunk encapsulation dot1q

switchport mode trunk

3/22/12 update: We've finally retired the old Extreme switches. I am happy to say that this LACP trunk config performed perfectly for nearly 5 months to tie a new Cisco infrastructure to an old Extreme one. 

I should post before a year has passed.

Being this is a "free time" blog, this exemplifies the last year quite well. This last year has been one of the most challenging I can remember. A couple quick updates to keep it less than a year old:

- I'm working with MSDeploy to build a continuous integration model. I aspire to post my findings here. It has been exceptionally promising thus far.
- Baby #2 is due within the next few weeks. I'm very excited and a bit nervous at the same time.
- Amplifier released their new (pseudo?) concept album The Octopus. Initially I didn't care for it as much as I had hoped, but now that I've given it about 3 listens it's really sticking in my brain.

App-V, WAS 6.1 is the final 6.0, We have a child!

Just moved + baby + 80 hr workweeks=not much spare time. I don't have any time to type out valuable information, but in the interest of making it look like I still care here are some very brief updates:

• I've been experimenting with Microsoft Application Virtualization via "App-V". (Apps over RDP) The implementation is impressive; I'm even running outlook full time without having it installed on my PC. There are some key limitations that prevent enterprise class adoption however: Load balancing options are limited, (this is being worked on) it doesn't operate quite correctly on the desktop side with the Aero interface, and there are at this point no ways to control the "branching" behavior of the app in question. For example, if you get an e-mail with an http: link there is no way to control where that link is opened. At this point all links, etc. default to opening within your RDP session on the server and a new virtualized app is created to facilitate that. Obviously there are few scenarios where you want to virtualize IE at this point in time due to the rendering requirements.
• Quick point; WAS 6.1 is a major improvement over WAS 6.0 in terms of manageability. I am eager to work in depth with 7.0. I have figured out how to run Websphere Application Servers on the Windows platform without administrative privileges for the service account associated with the process. I was very disappointed to find that IBM didn't know this information, so I had to "go it alone". The very limited guidance their tier 3 support was able to offer was inaccurate, and I got the feeling that their expertise level on the Windows platform is somewhat limited. I suppose I should be surprised by that... anyhow the details are a little lengthy to type out at this time, so if interested shoot me an e-mail and I'll help you out. Also quickly re: WAS, be aware of this issue if using WAS with IIS 6.0/certificate authentication : http://blogs.msdn.com/jiruss/archive/2007/04/13/http-413-request-entity-too-large-can-t-upload-large-files-using-iis6.aspx (look how much more interesting that guy's blog is than mine. Must be focus.)
• My kid is the cutest kid ever, but I may be slightly biased. Not sure.
• My friend turned me on to a band that is absolutely amazing; I haven't enjoyed the collective works (only 3 albums mind you) of one band as much as this in quite some time. If you like progressive rock please give 'em a shot: http://www.amplifiertheband.com/
• Tech PSA: If you're on the Google Wave preview program, please sign on. I have about 20 friends on there and not one of them has signed on in the last week. It's awkward sending all these waves back and forth to myself. ;-D

See ya!

TVersity/Websphere Security

Working on my basement & trying to get the XBOX 360 as a usable media viewing platform for my wife. My goal is to have it be the central point of her living room, as I'm moving my main HTPC downstairs with me. :D I have my 500 movie collection ripped to a couple TB drives and encoded in various different formats. Since I don't want to re-rip them all to supported 360 formats (UGH! http://blogs.msdn.com/xboxteam/default.aspx) I've been looking into TVersity. (www.tversity.com) I'm trying to get it up and running on my dedicated server. Here are a couple tech notes that pertain to getting this to work:

-As they state, disable SSDP and UPNP services inherent to Win2k8. The software has it's own UPNP code.
-If you have a multi homed box, make sure you use whatever interface your machine likes to dish out in ARP communications. This one is kinda odd.... I haven't figured out all the details yet, but my server makes ARP requests and dishes out the IP of it's secondary interface to communicate. I had to bind the TVersity server service to that IP specifically to get clients to connect reliably. Had to use wireshark to figure this one out.
-Your server needs a soundcard to build the graph to transcode videos. I believe this to be a OS limitation, as it uses the native windows codec priority to build graphs, and you can't build a transcoding graph without an audio out pin. This is disappointing, as the only sound card I have lying around is a creative card and I REALLY don't want to install a creative labs sound card on a server due to YEARS OLD DRIVER ISSUES CREATIVE IS HORRIBLE GAH WHY DO I STILL BUY THEIR PRODUCTS SOMETHING IS WRONG WITH MY BRAIN.... sorry that just spilled out.

Enough of that. From a more professional perspective, I've been trying to get real keystores working throughout an implementation of Websphere 6.0.2.x ND Application Server(s). After much trial and error, let me make the following recommendations as to how to pursue this:

1. Do Not: make a new repitoire. This is unfortunate, but IBM's implementation of repitoire management is lacking at best, horrible and unworkable at worst. Even if you go through the trouble to change all web container referance points to the new keys, you will still have to scour other config files manually (mainly server.xml files) to replace references. This is obviously prone to error. I reccomend instead replacing the default keystores and truststores (under websphere\appserver\profiles\\etc\dummy*.jks with your real keys.
2. Do: change the password on the default keystore after you update it. This won't cause issues with two exceptions... you will have to update the passwords in \websphere\appserver\profiles\\properties\sas.client.props and soap.client.props with the new passwords. Make sure to encrypt the files after you do so using IBM's encryption script.
3. Do: delete ALL "dummy" keys and expired certs from all stores. No reason to keep them, it's just a security risk.
4. Do: update the plugin keystore if you use a web server front-end. You just need to make sure that the keystore/truststore (this one should be shared) has your issuing CA chain. Note that this keystore is in CMS format and you'll need to use the GSK7 version of ikeyman to update it. If it doesn't launch properly make sure you have JAVA_HOME set to \websphere\appserver\java\ .

Anyhow, I'm going to try to update this more regularly (and my failure to do so will be for all to see...) to have a repository for "gotcha" info I haven't been able to find anywhere else on the internet. This will serve two purposes: 1. We go through so much I can't seem to remember this stuff later, so I'll have documentation of it... 2. Hopefully others will stumble across this info and find it useful since I haven't found it anywhere else.

On the music font, Coheed and Cambria is amazing. I can't stop listening to their 2k5 album release.