1. 網站打不開的問題
當遇到網站打不開的問題時，首先要分析可能的原因。一種常見的提示是「Service Unavailable」，這可能是由於網站超過了一些限制導致的。例如，系統資源被佔用太多，或網站的程序導致的資源消耗過高。在Windows 2003操作系統中，當網站超過IIS連接數時，並不會像在Windows 2000系統中提示「鏈接人數過多」，而是直接顯示為「Service Unavailable」。
對於沒有限制IIS連接數，但還是遭遇「Service Unavailable」提示的情況，通常與使用ACCESS資料庫的網站有關。這可能是由於資料庫引擎出現問題，導致系統資源被大量佔用。通過使用伺服器醫生的文件醫生進行修復，可以發現並解決導致ACCESS引擎出現「災難性故障」和「未將對象引用設置到對象的實例」錯誤的文件問題。
在瀏覽Windows SharePoint Services Web 站點時遇到「Service Unavailable」問題，可能是因為IIS 6.0中沒有正確配置用於虛擬伺服器的應用程序池。為了解決這個問題，需要驗證是否已經配置了應用程序池，並檢查應用程序池賬戶的密碼是否正確，以及確認該賬戶是否屬於IIS_WPG和STS_WPG組。重啟IIS以回收應用程序池也是解決此問題的一種方法。
另一個常見原因可能是ISAPI篩選器沒有成功載入。在這種情況下，解決方法包括根據載入失敗的原因進行解決，或者刪除該ISAPI篩選器。為了排除其他可能的原因，比如非法攻擊導致的網站流量過大，需要監控和分析日誌文件，以便確定具體原因並採取相應的措施。
總結而言，解決網站「Service Unavailable」問題需要根據具體情況進行分析，可能涉及增加IIS連接數、增加資源、修改程序錯誤、重啟IIS，或者修復或刪除ISAPI篩選器等方法。通過細心排查和針對性處理，大多數情況下可以有效解決這類問題，使得網站恢復正常訪問。
2. 聲明身份驗證不驗證用戶
摘要：由於 SharePoint 2013 建議在用戶訪問 Web 應用程序時使用基於聲明的身份驗證，因此本文介紹可供您用來對失敗的基於聲明的用戶身份驗證嘗試進行故障排除的工具和方法。
當用戶嘗試連接到 Web 應用程序時，日誌將記錄失敗的身份驗證事件。如果您使用 Microsoft 提供的工具並使用一種系統方法來檢查失敗，則可以了解與基於聲明的身份驗證相關的常見問題並予以解決。
需要身份驗證和授權才能成功訪問 SharePoint 資源。當您使用聲明時，身份驗證將驗證安全令牌是否有效。授權將根據安全令牌中的聲明集和資源的已配置許可權來驗證是否允許訪問該資源。
若要確定身份驗證或授權是否會引發訪問問題，請在瀏覽器窗口中仔細查看錯誤消息。
如果錯誤消息指示用戶不具有對網站的訪問許可權，則表示身份驗證成功，但授權失敗。若要對授權進行故障排除，請嘗試以下解決方案：
在使用基於安全聲明標記語言 (SAML) 聲明的身份驗證時發生授權失敗的最常見原因是，許可權將分配給用戶的基於 Windows 的帳戶（域\用戶）而不是分配給用戶的 SAML 標識聲明。
確保已將用戶或用戶所屬的組配置為使用適當的許可權。有關詳細信息，請參閱 SharePoint 2013 中的用戶許可權和許可權級別。
使用本文中所述的工具和方法來確定用戶的安全令牌中的聲明集，以便您可以將其與已配置的許可權進行比較。
如果消息指示身份驗證失敗，則表示出現了身份驗證問題。如果資源包含在使用基於聲明的身份驗證的 SharePoint Web 應用程序中，請使用本文中的信息來開始進行故障排除。
故障排除工具
以下是 Microsoft 提供的用於收集有關 SharePoint 2013 中的聲明身份驗證的信息的主要故障排除工具：
使用統一日誌記錄系統 (ULS) 日誌可獲取身份驗證事務的詳細信息。
使用管理中心可驗證 SharePoint Web 應用程序和區域的用戶身份驗證設置的詳細信息並配置 ULS 日誌記錄的級別。
如果您將 Active Directory Federation Services 2.0 (AD FS) 用作基於安全聲明標記語言 (SAML) 的聲明身份驗證的聯合提供程序，則可以使用 AD FS 日誌記錄來確定 AD FS 向 Web 客戶端計算機發出的安全令牌中的聲明。
使用網路監視器 3.4 可捕獲並檢查用戶身份驗證網路流量的詳細信息。
設置 ULS 日誌記錄的級別以進行用戶身份驗證
以下過程將 SharePoint 2013 配置為記錄聲明身份驗證嘗試的最大數量的信息。
配置 SharePoint 2013 以實現最大數量的用戶身份驗證日誌記錄
在管理中心中，在「快速啟動」上單擊「監控」，然後單擊「配置診斷日誌記錄」。
在類別列表中，展開「SharePoint Foundation」，然後選擇「身份驗證授權」和「聲明身份驗證」。
在「要報告給事件日誌的關鍵程度最低的事件」中，選擇「詳細」。
在「要報告給跟蹤日誌的關鍵程度最低的事件」中，選擇「詳細」。
單擊「確定」。
若要在未執行聲明身份驗證故障排除的情況下優化性能，可執行以下步驟來將用戶身份驗證日誌記錄設置為其默認值。
配置 SharePoint 2013 以實現默認數量的用戶身份驗證日誌記錄
在管理中心中，在「快速啟動」上單擊「監控」，然後單擊「配置診斷日誌記錄」。
在類別列表中，展開「SharePoint Foundation」，然後選擇「身份驗證授權」和「聲明身份驗證」。
在「要報告給事件日誌的關鍵程度最低的事件」中，選擇「信息」。
在「要報告給跟蹤日誌的關鍵程度最低的事件」中，選擇「中」。
單擊「確定」。
配置 AD FS 日誌記錄
即使在啟用最高級別的 ULS 日誌記錄後，SharePoint 2013 也不會記錄其收到的安全令牌中的一組聲明。如果您將 AD FS 用於基於 SAML 的聲明身份驗證，則可以啟用 AD FS 日誌記錄，並使用事件查看器來檢查 SharePoint 2013 發出的安全令牌的聲明。
啟用 AD FS 日誌記錄
在 AD FS 伺服器上的事件查看器中，單擊「視圖」，然後單擊「顯示分析和調試日誌」。
在事件查看器控制台樹中，展開「應用程序和服務日誌/AD FS 2.0 跟蹤」。
右鍵單擊「調試」，然後單擊「啟用日誌」。
打開 %ProgramFiles%\Active Directory Federation Services 2.0 文件夾。
使用記事本打開「Microsoft.IdentityServer.ServiceHost.Exe.Config」文件。
單擊「編輯」，再單擊「查找」，鍵入「<source name=「Microsoft.IdentityModel「 switchValue="Off">」，然後單擊「確定」。
將「switchValue="Off"」更改為「switchValue="Verbose"」。
單擊「文件」，再單擊「保存」，然後退出記事本。
從「服務」管理單元中，右鍵單擊「AD FS 2.0 服務」，然後單擊「重新啟動」。
您現在可以使用 AD FS 伺服器上的事件查看器來檢查有關「應用程序和服務日誌/AD FS 2.0 跟蹤/調試」節點中的聲明的詳細信息。查找事件 ID 為 1001 的事件。
還可以使用 HttpMole 或 Web 部件或通過 OperationContext 來枚舉聲明。有關詳細信息，請參閱如何在 SharePoint 2010 中進行聲明擴充時獲取所有用戶聲明。有關 SharePoint 2010 的此信息還適用於 SharePoint 2013。
聲明用戶身份驗證方法疑難解答
下列步驟可幫助您確定導致聲明身份驗證嘗試失敗的原因。
第 1 步：確定失敗的身份驗證嘗試的詳細信息
若要獲取有關某個失敗的身份驗證嘗試的最可靠的詳細信息，您必須在 SharePoint ULS 日誌中找到此嘗試。這些日誌文件存儲在 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS 文件夾中。
您可以通過手動或使用 ULS Log Viewer 在 ULS 日誌文件中查找失敗的身份驗證嘗試。
手動查找失敗的身份驗證嘗試
從用戶處獲取生成的失敗的身份驗證嘗試的用戶帳戶名。
在運行 SharePoint Server 或 SharePoint Foundation 的伺服器上，查找 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS 文件夾。
在 LOGS 文件夾中，單擊「修改日期」以按日期對文件夾進行排序，其中最新的文件夾將位於頂部。
再次嘗試身份驗證任務
在 LOGS 文件夾窗口中，雙擊列表頂部的日誌文件以在記事本中打開該文件。
在「記事本」中，單擊「編輯」，再單擊「查找」，鍵入「身份驗證授權」或「聲明身份驗證」，然後單擊「查找下一個」。
單擊「取消」，然後閱讀「消息」列的內容。
若要使用 ULS Viewer，請從 ULS Viewer 進行下載，並將其保存到運行 SharePoint Server 或 SharePoint Foundation 的伺服器上的文件夾中。在安裝此查看器後，請執行以下步驟來查找失敗的身份驗證嘗試。
使用 ULS Viewer 查找失敗的身份驗證嘗試
在運行 SharePoint Server 或 SharePoint Foundation 的伺服器上，在存儲 Ulsviewer 的文件夾中雙擊它。
在「ULS Viewer」中，單擊「File」，並指向「Open From」，然後單擊「ULS」。
在「Setup the ULS Runtime feed]」對話框中，確保在「Use ULS feed from default log-file directory」中指定 %CommonProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS 文件夾。如果未指定，請單擊「Use directory location for real-time feeds」，並在「Log file location」中指定 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS 文件夾。
對於 %CommonProgramFiles%，請將其替換為運行 SharePoint Server 或 SharePoint Foundation 的伺服器的 CommonProgramFiles 環境變數中的值。例如，如果位置是驅動器 C，則將 %CommonProgramFiles% 設置為 C:\Program Files\Common Files。
單擊「OK」。
單擊「Edit」，然後，單擊「Modify Filter」。
在「Filter by」對話框的「Field」中，單擊「Category」。
在「Value」中鍵入「Authentication Authorization」或「Claims Authentication」，然後單擊「OK」。
重復身份驗證嘗試。
從「ULS Viewer」窗口中，雙擊顯示的行以查看「Message」部分。
從非 OAuth 請求的「消息」部分的聲明編碼部分中，可以通過基於聲明的字元串（示例：i:0#.w|contoso\chris）確定身份驗證方法和已編碼的用戶標識。有關詳細信息，請參閱 SharePoint 2013 和 SharePoint 2010 聲明編碼。
第 2 步：檢查配置要求
若要確定如何配置 Web 應用程序或區域以支持一個或多個聲明身份驗證方法，請使用 SharePoint 管理中心網站。
驗證 Web 應用程序或區域的身份驗證配置
從管理中心中，單擊「快速啟動」上的「應用程序管理」，然後單擊「管理 Web 應用程序」。
單擊用戶正嘗試訪問的 Web 應用程序的名稱，並在功能區的「安全性」組中，單擊「身份驗證提供程序」。
在身份驗證提供程序的列表中，單擊適當的區域（如「默認」）。
在「編輯身份驗證」對話框的「聲明身份驗證類型」部分，驗證聲明身份驗證的設置。
對於 Windows 聲明身份驗證，確認已選擇「啟用 Windows 驗證」和「集成的 Windows 驗證」，並確認已根據需要選擇「NTLM」或「協商(Kerberos)」。如果需要，可以選擇「基本身份驗證」。
對於基於窗體的身份驗證，確保已選擇「啟用基於窗體的身份驗證(FBA)」。確認「ASP.NET 成員身份提供程序名稱」和「ASP.NET 角色管理器名稱」中的值。這些值必須與您在 SharePoint 管理中心網站、Web 應用程序和 SharePoint Web Services\ 的 web.config 文件中配置的成員資格提供程序和角色值相匹配。有關詳細信息，請參閱在 SharePoint 2013 中為基於聲明的 Web 應用程序配置基於表單的身份驗證。
對於基於 SAML 的聲明身份驗證，確認已選擇「信任的身份提供程序」和正確的受信任提供程序名稱。有關詳細信息，請參閱在 SharePoint 2013 中使用 AD FS 配置基於 SAML 的聲明身份驗證。
在「登錄頁 URL」部分，確認登錄頁的選項。對於默認登錄頁，應選擇「默認登錄頁」。對於自定義登錄頁，確認自定義登錄頁的指定 URL。若要驗證該 URL，請將其復制，然後嘗試使用 Web 瀏覽器對其進行訪問。
單擊「保存」保存對身份驗證設置所做的更改。
重復身份驗證嘗試。對於基於窗體的或基於 SAML 的身份驗證，預計的登錄頁在顯示時是否會包含適當的登錄選項？
如果身份驗證仍失敗，請查看 ULS 日誌以確定在身份驗證配置更改之後和之後進行的身份驗證嘗試之間是否存在任何差異。
第 3 步：要檢查的其他項
在您查看日誌文件和 Web 應用程序配置後，請確認：
Web 客戶端計算機上的 Web 瀏覽器支持聲明。有關詳細信息，請參閱在 SharePoint 2013 中規劃瀏覽器支持。
對於 Windows 聲明身份驗證，請確認：
用戶從其中發出身份驗證嘗試的計算機是承載 SharePoint Web 應用程序的伺服器所在的域的成員或受宿主伺服器信任的域的成員。
用戶從其中發出身份驗證嘗試的計算機已登錄到其 Active Directory 域服務 (AD DS) 域。在命令提示符處或在 Web 客戶端計算機上的 SharePoint 2013 命令行管理程序 中鍵入 nltest /dsgetdc: /force 以確保其可以訪問域控制器。如果未列出域控制器，請解決 Web 客戶端計算機和 AD DS 域控制器之間缺少可發現性和連接的問題。
運行 SharePoint Server 或 SharePoint Foundation 的伺服器已登錄到其 AD DS 域。在命令提示符處或在運行 SharePoint Server 或 SharePoint Foundation 的伺服器上的 SharePoint 2013 命令行管理程序 中鍵入 nltest /dsgetdc: /force 以確保其可以訪問域控制器。如果未列出域控制器，請解決運行 SharePoint Server 或 SharePoint Foundation 的伺服器和 AD DS 域控制器之間缺少可發現性和連接的問題。
對於基於窗體的身份驗證，請確認：
配置的 ASP.NET 成員身份和角色提供程序的用戶憑據是正確的。
網路上已提供承載 ASP.NET 成員身份和角色提供程序的系統。
自定義登錄頁正確收集和傳達了用戶憑據。若要測試這一點，請將 Web 應用程序配置為臨時使用默認登錄頁並確保其正常運行。
對於基於 SAML 的聲明身份驗證，請確認：
配置的身份提供程序的用戶憑據是正確的。
網路上已提供用作聯合提供程序（如 AD FS）和身份提供程序（如 AD DS 或第三方身份提供程序）的系統。
自定義登錄頁正確收集和傳達了用戶憑據。若要測試這一點，請將 Web 應用程序配置為臨時使用默認登錄頁並確保其正常運行。
第 4 步：使用 Web 調試工具監視和分析 Web 流量
使用工具（如 HttpWatch或 Fiddler）分析以下類型的 HTTP 流量：
Web 客戶端計算機和運行 SharePoint Server 或 SharePoint Foundation 的伺服器之間的流量
例如，您可以監視運行 SharePoint Server 或 SharePoint Foundation 的伺服器發送的 HTTP 重定向消息以將聯合伺服器（如 AD FS）的位置告知 Web 客戶端計算機。
Web 客戶端計算機和聯合伺服器（如 AD FS）之間的流量
例如，您可以監視 Web 客戶端計算機發送的 HTTP 消息以及聯合伺服器的響應，其中包括安全令牌及其聲明。
注釋注意：
如果您使用 Fiddler，則身份驗證嘗試將在要求三次身份驗證提示後失敗。若要阻止此行為，請參閱將 Fiddler 與 SAML 和 SharePoint 結合使用以通過三次身份驗證提示.
第 5 步：捕獲和分析身份驗證網路流量
使用網路流量工具（如網路監視器 3.4）可捕獲和分析 Web 客戶端計算機、運行 SharePoint Server 或 SharePoint Foundation 的伺服器以及 SharePoint Server 或 SharePoint Foundation 進行聲明身份驗證所依賴的系統之間的流量。
注釋注意：
在許多情況下，聲明身份驗證使用基於安全超文本傳輸協議 (HTTPS) 的連接，這將對計算機之間發送的消息進行加密。在不藉助載入項或擴展的情況下，您無法使用網路流量工具查看已加密的消息的內容。例如，對於網路監視器，您必須安裝和配置 Network Monitor Decryption Expert。作為嘗試解密 HTTPS 消息的更簡單的替代方式，可使用承載 SharePoint Server 或 SharePoint Foundation 的伺服器上的工具（如 Fiddler），這將報告未加密的 HTTP 消息。
分析網路流量可獲知：
在聲明身份驗證過程中涉及的計算機之間發送的協議和消息的准確集合。答復消息可以包含錯誤條件信息，您可以根據此信息確定其他故障排除步驟。
請求消息是否獲得相應答復。如果多個已發送請求消息未收到答復，則表示網路流量未達到其預定目標。在此情況下，請檢查數據包路由問題，路徑中的數據包篩選設備（如防火牆）或目標上的數據包篩選（如本地防火牆）。
是否嘗試了多種聲明方法以及哪些方法失敗。
對於 Windows 聲明身份驗證，您可以捕獲和分析下列計算機之間的流量：
Web 客戶端計算機和運行 SharePoint Server 或 SharePoint Foundation 的伺服器
運行 SharePoint Server 或 SharePoint Foundation 的伺服器和其域控制器
對於基於窗體的身份驗證，您可以捕獲和分析下列計算機之間的流量：
Web 客戶端計算機和運行 SharePoint Server 或 SharePoint Foundation 的伺服器
運行 SharePoint Server 或 SharePoint Foundation 的伺服器和 ASP.NET 成員身份和角色提供程序
對於基於 SAML 的聲明身份驗證，您可以捕獲和分析下列計算機之間的流量：
Web 客戶端計算機和運行 SharePoint Server 或 SharePoint Foundation 的伺服器
Web 客戶端計算機和其身份提供程序（如 AD DS 域控制器）
Web 客戶端計算機和聯合提供程序（如 AD FS）
3. OfficeWebApps錯誤日誌
最近一直在用Office Web Apps，使用過程會有各種各樣的錯誤，眾所周知，sharepoint的錯誤都在15/Logs下面保存錯誤日誌，那麼OWA呢？
經過查找，發現Office Web Apps也有自己的錯誤日誌，如果我們遇到錯誤了，可以去查看錯誤日誌。
查看方法
默認錯誤日誌位置：
C:
很多環境中C盤可能空間有限，我們可以將錯誤日誌默認指向其他位置么？答案當然是可以的，我們可以通過Powershell命令來修改。
我們在New-OfficeWebAppsFarm的時候，其實是有LogLocation的屬性的，只不過是可選的屬性，我們可能並沒有選擇，默認的位置就是
%programdata%
那是不是說，我們如果想修改日誌默認位置，就需要重新創建場呢？當然不是了，我們還可以通過powershell命令去修改場。
Set-OfficeWebAppsFarm [-LogLocation ]
當然，這里只是說設置默認位置，如果你有其他屬性要設置，請參照官方文檔。
官方文檔
https://technet.microsoft.com/en-us/library/jj219442.aspx
4. 如何收縮超大的SharePoint
SQL Server日誌清空方法 在查詢分析器中順序執行以下三步，其中 databasename 為你的資料庫文件名 1.清空日誌：DUMP TRANSACTION databasename WITH NO_LOG 2.截斷事務日誌：BACKUP LOG databasename WITH NO_LOG 3.收縮資料庫：DBCC SHRINKDATABASE(databasename) --////////////////////////////////////////////////////////////////// SQL Server日誌清空方法 一種方法：清空日誌。 1．打開查詢分析器，輸入命令 DUMP TRANSACTION 資料庫名 WITH NO_LOG 2.再打開企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。 方法二： 清空日誌： ------------------------------------------ BACKUP LOG 庫名 WITH NO_LOG DBCC SHRINKFILE( '日誌文件名 ',新的大小數值型如1) 日誌文件名是這樣的: select name from sysfiles 如: mastlog --------------------------------------------- backup log DATABASENAME with truncate_only dbcc shrinkdatabase (DATABASENAME,SIZE) 若每天有whole back up 的話可以設置一job， 每隔三天或一個星期清空一次 這樣的話日誌就不會長大了哦 ------------------------------------- 1: 刪除LOG 1：分離資料庫 2：刪除LOG文件 3：附加資料庫 此法生成新的LOG，大小隻有500多K 再將此資料庫設置自動收縮 2:清空日誌 DUMP TRANSACTION 庫名 WITH NO_LOG 再： 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了 方法三： 第一步： backup log database_name with no_log 或者 backup log database_name with truncate_only --no_log和truncate_only是在這里是同義的，隨便執行哪一句都可以 第二步： 1.收縮特定資料庫的所有數據和日誌文件，執行 dbcc shrinkdatabase (database_name,[,target_percent])--database_name是要收縮的資料庫名稱；target_percent是資料庫收縮後的資料庫文件中所要的剩餘可用空間百分比 2.收縮一次一個特定資料庫中的數據或日誌文件，執行 dbcc shrinkfile(file_id,[,target_size]) --file_id是要收縮的文件的標識 (ID) 號,若要獲得文件 ID，請使用 FILE_ID 函數或在當前資料庫中搜索 sysfiles；target_size是用兆位元組表示的所要的文件大小（用整數表示）。如果沒有指定，dbcc shrinkfile 將文件大小減少到默認文件大小 兩個dbcc都可以帶上參數notruncate或truncateonly，具體意思看幫助。 方法四： （這個方法在sqlserver2000的環境下做一般能成功，在sqlserver7及以下版本就不一定了）： 第一步： 先備份整個資料庫以備不測 第二步： 備份結束後，在Query Analyzer中執行如下的語句： exec sp_detach_db yourDBName,true --卸除這個DB在MSSQL中的注冊信息 第三步： 到日誌的物理文件所在的目錄中去刪除該日誌文件或者將該日誌文件移出該目錄 第四步： 在Query Analyzer中執行如下的語句： exec sp_attach_single_file_db yourDBName, 'd:\mssql7\data\yourDBName_data.mdf ' --以單文件的方式注冊該DB，如果成功則MSSQL將自動為這個DB生成一個500K的日誌文件。 以上方法在清除log日誌中均有效。 但，能否讓sql server 不產生log日誌呢？以上方法好像均無效。 我這兒正好有個case： 我客戶的sql server每天都會產生4，500M的log日誌，每天都清除一下，非常不便。有沒有辦法實現不產生log日誌呢？ 我分析了一下客戶產生log日誌的原因，並且做了相應測試。 客戶是每天將資料庫清空，從總系統中將數據導入到sql server里。我感決sqlserver在插入時產生log不大，在delete整個庫時產生log極大。 比如： SELECT * into test_2 from b_bgxx 共45000條記錄，產生十幾M log，如果 delete from test_2 產生80多M log ，這明顯存在問題。 雖然可以換成： truncate table test_2 但我還是希望能找到不產生log的方法。就如oracle不產生歸檔一樣。