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不产生归档一样。