After further investigation, I determined that the file had originally been a .DOCX (the new file format for Word 2007), I changed the file extension back to .DOCX and attempted to open the file again. Word was now able to open the document.  It seems that the sender of the document manually changed the file extension from .DOCX to .DOC, rather than opening the document in Word and saving it in the desired format.

For example, I had a duplicate entry for host/cit10.xxxxdom1

1. From the domain controller, open a command prompt and then type the following string:
ldifde -f domain.txt -d dc=domain,dc=com

2. Open the text file in Notepad and then search for the SPN that is reported in the event log.
ie. host/cit10.xxxxdom1

3. Note the user accounts under which the SPN is located and the organizational unit the accounts reside in and determine which one is incorrect.  In my example, one computer had both a correct spn (host/compna0003.xxxxdom1) and a duplicate spn (host/cit10.xxxxdom1) right below it that another PC also (correctly) had.  I noted the where the offender was located in the AD hierarchy.

Then once the above has been located use the Windows Support Tools utility ADsiedit

Using ADSIEdit
1. Add ADSIEdit to the MMC and bind to the domain using the Domain well known naming context.
2. Navigate to each user account you previously documented as having a duplicate SPN registration and right click the account and select properties.
3. Scroll through the list of attributes until you see ServicePrincipalName, double click ServicePrincipalName and remove the duplicate SPN registration and click on OK and exit ADSIEdit.

First stop in my troubleshooting process was to look at the System Log within the ASDM for the ASA. I then tried to initialize the PPTP connection, I saw within the System Log the following error:
“regular translation creation failed for protocol 50 src inside:(Machine name) dst outside:(IP Address)”

After some research as to why this was happening, I was able to note that this is not something that is configured by default. You must put in a command within the CLI (Command Line Interface) that allows PPTP packets to be inspected. The firewall then creates dynamic GRE (generic routing encapsulation) connections and translations necessary to permit PPTP traffic. Here are a list of the commands that I had to execute within my firewall:

ASA5505> enable
Password: ********
ASA5505# conf t
ASA5505(config)# policy-map global_policy
ASA5505(config-pmap)# class inspection_default
ASA5505(config-pmap-c)# inspect pptp

After doing this, I then tested connectivity and it successfully worked. I found that this could be a big help in future firewall configurations where you must connect to various client PPTP VPN’s when you are behind a Cisco firewall.  Don’t forget to save your configuration after you have tested this successfully!

The most simple way to go about this is to do the following after connecting to the outside interface of the PIX via Putty:

Step 1: Login to the PIX via Putty
Step 2: Enter in the username and password
Step 3: Type “enable” (without the quotations)
Step 4: Enter in the password again
Step 5: Type “conf t”
Step 6: Type “no crypto map mymap client authentication radiusauth”
Step 7: Type “write mem”
Step 8: Type “exit”

At this point, you can connect to the Cisco VPN without having to authenticate.  Once the issue has been resolved with the domain controller, put radius authentication back to the way it was configured before.

Step 1: Login to the pix via Putty
Step 2: Enter in the username and password
Step 3: Type “enable”
Step 4: Type the password again for the PIX
Step 5: Type “conf t”
Step 6: Type “crypto map mymap client authentication radiusauth”
Step 7: Type “write mem”
Step 8: Type “exit”
Step 9: Attempt to connect back to the VPN and verify that you are prompted to authenticate.

The solution was found by changing the IAS Framing “Service-Type” to ‘login’, as the reply needs to only be a simple yes/no response and the WCS server doesn’t understand the additional framing.

1) Disrupt the normal SBS installation by using an ‘answer file’ stored on a USB drive; this allows you to tell it the existing domain / server information.

2) Once the new server is installed, you need to run adprep and forestprep on the Windows 2000 DC using the 2008 SBS media.

3) Once the Domain and Forest are prepared, you need to rename the ntds.dit file to sbsntds.dit (the ntds.dit file is Active Directory) on the Windows 2000 DC.

4) Now you can run ‘dcpromo’  on the new server and transfer over all of the FSMO roles.

5) Lastly, you need to Install / Configure Exchange 2007 manually, as it will not install by default when using this method.

Once step 5 is complete, you still are left with all of the normal configurations required with a new Windows 2008 SBS server; however, you won’t need to dis-join/re-join all of the machines and migrate all of the data/profiles across domains.

Good Luck!