欢迎光临,这里是 gOxiA=苏繁=SuFan 独立的个人博客。
本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m
转载文章,请务必保留出处与作者信息,未经许可严禁用于商业用途!

SP2010_logo

HOWTO: 重建 SharePoint Server 2010 的 User Profile Service Application

        SharePoint Server 2010 安装后,用户通常会启动向导创建一个 Web 应用程序,同时创建一个网站集,默认情况下系统会自动创建并配置 User Profile Service Application。这样网站用户便可以通过 SharePoint 网站界面右上角的用户图标来切换到“我的网站”,如果允许了“自助式网站创建”,那么用户在“我的网站”顶部导航里点击“我的内容”就会自动创建属于用户自己的文档工作区。

image

image

        对于新入手的用户如果对 SharePoint 的不熟悉很容易因误操作导致出现故障,gOxiA 最近在调试 SharePoint Server 2010 时就遇到了这样的问题,因为误操作删除了“我的网站”相关的配置,虽然 User Profile 的数据库还在但使用无法从浏览器访问“我的网站”提示404错误。期间也搜索了网上的相关文章,但都看得晕晕的。本以为重建“我的网站宿主”,重新配置 User Profile 就能解决,没想事与愿违!既然网上资料贫乏,只能用笨办法自己来搞定,随后单独又搭建了一套 SharePoint 环境,用于配置对比和测试,同时参考了 TechNet Library 的资料,最后决定通过重建 User Profile Service Application 来解决。

        为了保证能顺利进行并系统的实践,首先清理之前所有相关配置信息,删除之前手工创建的网站集-“我的网站”,删除之前添加的“管理路径”,最后在“服务应用程序”里删除系统自动创建的 User Profile Service Application。再次访问 SharePoint 网站会发现账号图标下已经没有“我的网站”和“我的档案”两个链接。现在开始重建 User Profile Service Application!

        首先,在“Web 应用程序”中选中站点,之后点击“管理路径”进入其配置界面。

image

        在“定义管理路径”配置页面中添加两个路径:“my”(类型:显示包含)、“my/personal”(类型:通配符包含)。各路径的类型不能有误!!!

image

        之后,为该 Web 应用程序创建网站集,标题可以随意命名,URL选择 my,因为是显示包含类型,所以后面不会再出现子路径。模板则选择“企业”下的“我的网站宿主”,在“网站集管理员”处添加对应账号,点击“确定”创建该网站集。

image

        “我的网站宿主”网站集创建完毕后可以访问只URL进行确认,因为还未创建 User Profile Service Application,所以会提示错误,如下图。

image

        现在再回到“服务应用程序”,如下图在“新建”下点击“User Profile Service Application”。

image

        如下图,在创建配置页面填写名称,如:User Profile Service Application,选择“使用现有应用程序池”-“SharePoint Web Services Default”,配置文件数据库、同步数据库、社会性标签数据库可使用默认名称,或自定义,之后拖动滚动条向下进行 URL 的配置。

image

        在“我的网站宿主 URL”处填写之前创建的网站集 URL,即:“http://moss/my”,在“我的网站管理路径”处确认是否为系统默认的“/personal”。

image

        最后一切确认无误后点击“创建”。随后向导会给出一个成功创建的反馈页面,如下图。

image

        现在重新打开 SharePoint 站点,访问“我的网站”已经能正常访问了。首次访问“我的内容”时系统会为当前账户创建对应的子站点,稍等片刻即好。

image

        如果如下图出现“无法创建您的个人网站…”的提示,则需要检查“自助式网站创建”是否被启用。如果用户之前已经成功创建了“我的内容”子站,那么即使之后管理员禁用“自助式网站创建”,用户还是能够访问已经创建的“我的内容”子站。

image

image

        至此,User Profile Service Application 的重建操作便以完成。

logo_winserver2012

HOWTO: 解决 Windows Server 2012 Hyper-V 实时迁移时遇到的 0x80090303 故障

        当我们在测试 Windows Server 2012 Hyper-V 实时迁移(如:无需共享存储的实时迁移)过程中可能会遇到 0x80090303 故障,错误如下图所示:

0x80090303

        具体内容大致为“迁移源上的虚拟机迁移操作失败。无法验证源主机上的连接:指定的目标未知或无法达到(0x80090303)。”由于 0x80090303 故障与之前日志中提到的 0x8009030E 故障极为相似,如果不加注意我们便会按照实时迁移时 kerberos 权限委派的步骤进行排错解决,去为主机委派设置添加“Microsoft Virtual System Migration Service”服务类型。gOxiA 当初就走入了这个误区,当使用 ADUC 为 Hyper-V 主机去做委派时发现在主机委派服务类型中并未找到“Microsoft Virtual System Migration Service”。

        检查 Hyper-V 主机事件日志发现在“应用程序和服务日志”-“Microsoft”-“Windows”-“Hyper-V-VMMS”-“Admin”下记录有错误的事件ID:14050,来源为:Hyper-V-VMMS。具体内容是“无法注册服务主体名称“Microsoft Virtual System Migration Service”。”

image

        此外,还包含其他几个相关的 SPN(服务主体名称)错误日志:“Hyper-V Replica Service”、“Microsoft Virtual Console Service”。之后使用 setspn –l hostname 进行检查,发现当前主机确实缺少这些 SPN,而“Microsoft Virtual System Migration Service”是我们迁移虚机所必须的。

        那么什么是 SPN 呢?!引用一篇微软官方 Blog 的解释:SPN 即“服务主体名称”,是一种名称,唯一标识一个服务实例。用来验证 Kerberos 身份验证的 SPN 的必须正确设置。SPN 是 Active Birectory 属性,但不暴露在 AD 的管理单元。那么 SPN 的作用是什么呢?!gOxiA 推荐这篇微软 Blog http://blogs.technet.com/b/crmchina/archive/2010/01/29/crm-spn.aspx 供大家参考,虽然与 Hyper-V 没有直接关系,但他们之间的概念是相通的,便于我们更好的理解该故障发生的原因。

        要解决该实时迁移过程中遇到的 0x80090303 故障,我们只需要手工在 Hyper-V 主机上对“Microsoft Virtual System Migration Service”进行 SPN 注册即可。为此,我们需要用到 setspn –s spnname/hostname(and FQDN) NetBIOSName 命令行,参考命令行如下:

setspn –s “microsoft virtual system migration service/hv3”hv3

setspn –s “microsoft virtual system migration service/hv3.contoso.com”hv3

        完成“Microsoft Virtual System Migration Service”的 SPN 注册后,我们便可以正常执行实时迁移,0x80090303 故障消失!按理说 SPN 的注册应该是自动的,但是为什么在 gOxiA 的实验环境下出现失败注册,可能跟 DC 是 SBS2011 有关,因为网上能找到类似的故障都是使用的 SBS2011 作为域控。当然也不排除其他可能存在的因素,在微软的 KB2761899 中就提及到了这个事件 ID,如果你也遇到这个问题,并排除 SBS2011 的原因,那么可以参考:http://support.microsoft.com/kb/2761899?wa=wsignin1.0 解决!

        关于 SPN 自动注册失败的原因及解决办法,gOxiA 会继续关注,一有答案便会跟大家分享!目前的办法只有使用 setspn 命令手工注册来解决!

  解决 PXE-E32, TFTP Time Out 故障一例

        这个月打完补丁后发现服务器上的 WDS 工作不正常,故障表现在客户端 PXE 启动后,无法 TFTP 下载数据,最终导致出现 TFTP Timeout 错误。查询相关资料,找到一篇 KB977512 按照其办法解决。

        原来,微软最近发布的一个针对 DNS 漏洞的更新导致了 WDS 和 DNS 在一台服务器上即会出现 PXE-E32, TFTP Time Out 的故障。Windows Server 2008 和 Windows Server 2008 R2 都受到了影响,微软 KB 中给出了各自的解决办法,以 gOxiA 的 Windows Server 2008 R2 环境为例,只需要修改注册表将 WDS 的 UdpPortPolicy 禁止即可。具体操作如下:

        使用 Regedit 打开注册表编辑器,找到如下路径,将“UdpPortPolicy”的值改为“0”,最后重新启动 WDS 服务即可!

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Parameters

        至此,故障解决!如果系统为 Windows Server 2008 可以参考 KB 修改 WDS 的 UDP 范围即可,当然也可以使用 wdsutil 命令直接进行修改“wdsutil /set-server /transport/startport:50000 /endport:65000”

分页: 1/6 第一页 1 2 3 4 5 6 下页 最后页 [ 显示模式: 摘要 | 列表 ]