你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
可以，但是需要修改appkey，在index.html里面修改。
要回复文章请先或
环信专业服务
知识价值的认可，源自您的赞赏
扫描二维码，你的支付将由imGeek代收后转给对方
感谢您的赞赏
一个开放、互助、协作、创意的社区
一个开放、互助、协作、创意的社区
京ICP备号-3（为 Exchange 管理员）配置 Outlook Web App 中的“更改密码”功能: Exchange 2010 帮助
不是 IT 专业人员？
（为 Exchange 管理员）配置 Outlook Web App 中的“更改密码”功能
（为 Exchange 管理员）配置 Outlook Web App 中的“更改密码”功能
Exchange 2010
适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3 上一次修改主题：
本文适用于 Exchange 管理员。如果您是用户并且想要在 Outlook Web App 中更改密码，请参阅。请注意，您的 Exchange 管理员可能未启用此功能。 Microsoft Office Outlook Web App 中的更改密码功能使域用户可以在使用 Outlook Web App 时更改其密码。本主题讨论更改密码功能以及 Exchange 管理员可以如何在 Microsoft Exchange Server 2010 中为用户启用此功能。
Windows Server 2008 或 Windows Server 2003 域中有三种类型的帐户策略：密码策略、帐户锁定策略和 Kerberos 身份验证协议策略。单个域将具有这三个策略之一。在 Active Directory 域中，您可以应用一个密码和帐户锁定策略。此密码在该域的默认域策略中指定。所配置的设置将应用于域中的所有用户。其中包括 Outlook Web App 用户。 密码和帐户锁定设置通过阻止用户猜测其他用户的帐户密码，来保护组织中的帐户和数据。可以使用默认域策略设置的“帐户锁定策略”和“密码策略”节点来配置帐户锁定策略和密码策略设置，这些设置将影响 Exchange 组织中的 Outlook Web App 用户，并将强制执行。密码策略包含下列设置：
密码复杂性
密码历史记录
最短密码长度
最长密码期限
最短密码期限
在创建用户帐户并为用户启用邮箱时，用户帐户的密码策略和设置将应用于该用户。但是，其他用户密码设置也可能影响 Outlook Web App 用户，例如“用户初次登录时必须更改密码”和“用户不能更改密码”。
默认情况下，用户用于访问基于 Windows 网络的域密码与用于访问 Outlook Web App 的密码相同。用户可以使用 Outlook Web App 中的“更改密码”功能，通过 Web 浏览器更改其域密码。 Outlook Web App 提供更改尚未过期的密码的功能。但是，如果密码已过期或在首次登录时需要更改，则不能通过 Outlook Web App 更改密码，除非您对客户端访问服务器进行了配置更改以启用更改过期的密码。 如果未启用更改过期的密码，则必须更改密码的用户需要与管理员联系，才能重置密码。当重置密码时，管理员必须清除“用户下次登录时必须更改密码”复选框。 如果未启用更改过期的密码且使用基于表单的身份验证，则必须更改密码的用户会返回到登录页面，并会显示以下错误消息：“输入的用户名或密码不正确。请重新尝试输入”。如果基于表单的身份验证未用于 Outlook Web App，则用户将返回到登录窗口，但不会看到任何错误消息。 重要说明：
对 Outlook Web App 使用基本身份验证或基于表单的身份验证时，如果用户使用的密码包含扩展的 ASCII 或 Unicode 字符，“更改密码”功能可能无法正常使用。这是由于使用扩展 ASCII 或 Unicode 字符的密码无法正确地在 IIS 与某些 Web 浏览器之间传输。建议 Outlook Web App 用户仅在将要使用 Outlook Web App 中的“更改密码”功能时，才使用 ASCII 字符。
可以通过配置用户邮箱，对单个用户启用或禁用更改密码功能，也可以通过配置 /owa 虚拟目录或用于 Outlook Web App 的其他虚拟目录，对多个用户启用或禁用更改密码功能。可以使用分段启用或禁用更改密码功能。有关详细信息，请参阅。
您必须先获得权限，然后才能执行此过程。若要查看所需的权限，请参阅 主题中的“Outlook Web App 注册表编辑器”条目。 警告：
不正确地编辑注册表时，可能导致出现严重问题，从而需要重新安装操作系统。因不正确地编辑注册表而导致出现的问题是能够解决的问题。在编辑注册表之前，请备份任何有用数据。
登录到客户端访问服务器。
启动注册表编辑器 (regedit)。
查找以下注册表子项：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA.
创建下面的 DWORD 值（如果该值尚不存在）：“ChangeExpiredPasswordEnabled”。值类型为 REG_DWORD。
将 ChangeExpiredPasswordEnabled 的值设置为 1。
退出注册表编辑器。
必须在支持 Outlook Web App 的每个客户端访问服务器上都进行此更改。
(C) 2010 Microsoft Corporation。保留所有权利。
此页面有帮助吗？
更多反馈？
1500 个剩余字符
我们非常感谢您的反馈。
页面加载速度够快吗？
您喜欢网页的设计吗？
请告诉我们更多意见如何解决不同的webApp的session 共享问题
如何解决不同的webApp的session 共享问题
复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。
cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。
cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。
关于session的设置参考[5] http://e-/wls/docs70/webapp/weblogic_xml.html#1036869
六、HttpSession常见问题
（在本小节中session的含义为⑤和⑥的混合）
1、session在何时被创建
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 &%@page session=&false&%& 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。
由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。
2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）
3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。
4、有个HttpSessionListener是怎么回事
你可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。
5、存放在session中的对象必须是可序列化的吗
不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在 Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化的对象，在session销毁时会有一个Exception，很奇怪。
6、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-/wls/docs70/webapp/sessions.html#100770
7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。
8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改操作，这样就可以不用设置。
9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。
10、为什么session不见了
排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者***在cookie处理上也有可能会出现问题。
出现这一问题的大部分原因都是程序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨论这个问题。
七、跨应用程序的session共享
常常有这样的情况，一个大项目被分割成若干小项目开发，为了能够互不干扰，要求每个小项目作为一个单独的web应用程序开发，可是到了最后突然发现某几个小项目之间需要共享一些信息，或者想使用session来实现SSO(single sign on)，在session中保存login的用户信息，最自然的要求是应用程序间能够访问彼此的session。
然而按照Servlet 规范，session的作用范围应该仅仅限于当前应用程序下，不同的应用程序之间是不能够互相访问对方的session的。各个应用服务器从实际效果上都遵守了这一规范，但是实现的细节却可能各有不同，因此解决跨应用程序session共享的方法也各不相同。
首先来看一下Tomcat是如何实现web应用程序之间session的隔离的，从Tomcat设置的cookie路径来看，它对不同的应用程序设置的cookie路径是不同的，这样不同的应用程序所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程序，发送给服务器的session id也可以是不同的。
根据这个特性，我们可以推测Tomcat中session的内存结构大致如下。
笔者以前用过的iPlanet也采用的是同样的方式，估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思路很简单，实际实行起来也不难。要么让所有的应用程序共享一个session id，要么让应用程序能够获得其他应用程序的session id。
iPlanet中有一种很简单的方法来实现共享一个session id，那就是把各个应用程序的cookie路径都设为/（实际上应该是/NASApp，对于应用程序来讲它的作用相当于根）。
&session-info&
&path&/NASApp&/path&
&/session-info&
需要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程序的前缀，使得setAttribute(&name&, &neo&)变成setAttribute(&app1.name&, &neo&)，以防止命名空间冲突，导致互相覆盖。
在Tomcat 中则没有这么方便的选择。在Tomcat版本3上，我们还可以有一些手段来共享session。对于版本4以上的Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手段。
我们再看一下Weblogic Server是如何处理session的。
从截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就可以共享session了呢？然而一个小实验即可证明即使不同的应用程序使用的是同一个session，各个应用程序仍然只能访问自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下
对于这样一种结构，在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据库、JMS或者客户端 cookie，URL参数或者隐藏字段等手段，还有一种较为方便的做法，就是把一个应用程序的session放到ServletContext中，这样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，
context.setAttribute(&appA&, session);
contextA = context.getContext(&/appA&);
HttpSession sessionA = (HttpSession)contextA.getAttribute(&appA&);
值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器可以处于安全的原因对于context.getContext(&/appA&);返回空值，以上做法在Weblogic Server 8.1中通过。
那么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程序都可以共享认证的信息。一个简单的实验就可以证明这一点，修改首先登录的那个应用程序的描述符weblogic.xml，把cookie路径修改为/appA访问另外一个应用程序会重新要求登录，即使是反过来，先访问cookie路径为/的应用程序，再访问修改过路径的这个，虽然不再提示登录，但是登录的用户信息也会丢失。注意做这个实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过session来实现的。具体请参看[7]
secion 14.8 Authorization，你可以修改所附的示例程序来做这些试验。
session机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。
关于作者：
郎云鹏（dev2dev ID: hippiewolf），软件工程师，从事J2EE开发
电子邮件：.cn
地址：大连软件园路31号科技大厦A座大连博涵咨询服务有限公司
我的热门文章
即使是一小步也想与你分享