傳統的ASP移植到WINDOWS SERVER 2008-2012 系統，網路上已經有很多文件說明。因為傳統ASP是32位元程式，在64位元系統，IIS 7 裡面的 appPool都要調整成允許32位元程式執行運作。ODBC 也得使用 SYSWOW64 裡面的 odbcad32.exe 進行設定。

不過，很少人提到以前的3-tier架構的ASP網站，都還有中間層 middle-tier，一般都是COM DLL，或稱COM元件。

以下就是我的例子，移植一個傳統ASP 3-tier 網站至Windows Server 2008 R2 64位元作業系統:

傳統ASP 3-tier 網站，原先架構於 Windows 2003 Server, IIS 6, COM DLL 為VB6撰寫，安裝在server 2003的「元件服務」上。

目的server為Windows Server 2008 R2 64位元

首先，ASP部分，本身物理路徑的讀寫權限，需搭配IUSER身份，或是自行指定IIS使用者，嚴格限制權限等等，就是一般的操作流程。我是建立新帳號，專門給這網站使用，給予該帳號讀寫該目錄及其以下所有目錄，檔案權限。等下也會用此新帳號，指定IIS 的APPPOOL 以及 COM DLL使用。此新帳號掛在IIS_Power Group 內統一指揮。

IIS 7 裡面，應用程式集區 appPool，新建一個 傳統，unmanaged

IIS 7 站台內，基本設定，相對應新的帳號與集區名稱為：

匿名驗證認證，相對應新的帳號為：

「元件服務」的內容為：

「元件服務」的識別碼內容，使用新帳號，為：

重點就在這裡，本來沒有這步驟，就造成ASP一直報錯-->伺服器物件 錯誤 'asp 0178 : 80070005' ,

權限認證失敗，查到一篇文章所提，跟著做設定，果然成功執行。這步驟卡了我半天。

ODBC 也要因應32，64位元系統的變換，而做調整。

請到 c:\Windows\SysWOW64 ，執行這支ODBC的32位元程式設定

odbcad32.exe

舊畫面，很熟悉。

當然，林林總總地，還有很多細節不及詳載，在此作為一個簡單筆記，希望日後遇到問題的朋友也能順利移植。