在以前SharePoint 2003 中，impersonate 是一个可以在sps 环境中使用所有功能的至高无上选择，通过impersonate 就可以通过Object Modal 的方式操作SharePoint 的所有功能。但是到了Microsoft Office SharePoint Server 2007 (moss2007 ，SharePoint Portal Server 2003 的后续版本) 这个又出现了新的变化，Impersonate 被丢弃了，而取而代之的是声称跟好的SPSecurity.RunWithElevatedPrivileges() ， 它通过传入一个无返回，无输入参数的委托作为参数，对委托的方法以提升权限后的身份去运行，来达到通过Object Modal 方式访问Moss 中所有资源和功能的目的。
在网上有些文章指出SPSecurity.RunWithElevatedPrivileges 这个方法实际上是用了IIS 中应用程序池中的用户去代替当前用户去运行，委托中的代码。这的确如此
但是这个方法并不是一步到位，直接的去使用应用程序池的用户，而是通过了一个所谓的“代理人”去完成这个事。无论在将Moss 的Web 应用程序部署为Windows 集成身份验证还是自定义的Forms 验证，在Moss 的所有列表库或文档库中的权限列表中，都会看到一个人，就是SHAREPOINT\System 这个用户，这个用户也是映射为当前的web 应用的网站集管理员，一般是第一个管理员。
Moss 2007 中，就是通过这个系统默认的管理帐号去模拟IIS 中应用程序池的用户，来达到对当前用户操作提升权限的效果。这就是说，其实在提升权限之后的一切操作都是以这个系统帐户(SHAREPOINT\system) 的身份去执行的，所以可以看到，若通过提升权限后进行的对文档库或列表进行添加、修改，在列表项的作者或修改人都会是系统帐户，而不是当前登录那个人的帐户，除非当前登录的人是网站集的管理员。
因为，SPSecurity.RunWithElevatedPrivileges 是通过模拟一个固定的帐户去进行操作，所以就带来了另一个问题，就是当这“代理人”系统帐户对列表或文档没有权限的时候，就像上图那样，系统帐户对列表的权限是受限访问，SPSecurity.RunWithElevatedPrivileges 就会不起作用，而且在代码的层面上很难发现这个问题。所以在需要通过调用SPSecurity.RunWithElevatedPrivileges来提升权限操作的列表或文档库，都需要确保系统帐户(SHAREPOINT\system)在该列表或文档库中存在，并且这个帐户的权限必须为完全控制。
这样调用提升权限时才会成功。
在网上有些文章指出SPSecurity.RunWithElevatedPrivileges 这个方法实际上是用了IIS 中应用程序池中的用户去代替当前用户去运行，委托中的代码。这的确如此
但是这个方法并不是一步到位，直接的去使用应用程序池的用户，而是通过了一个所谓的“代理人”去完成这个事。无论在将Moss 的Web 应用程序部署为Windows 集成身份验证还是自定义的Forms 验证，在Moss 的所有列表库或文档库中的权限列表中，都会看到一个人，就是SHAREPOINT\System 这个用户，这个用户也是映射为当前的web 应用的网站集管理员，一般是第一个管理员。
Moss 2007 中，就是通过这个系统默认的管理帐号去模拟IIS 中应用程序池的用户，来达到对当前用户操作提升权限的效果。这就是说，其实在提升权限之后的一切操作都是以这个系统帐户(SHAREPOINT\system) 的身份去执行的，所以可以看到，若通过提升权限后进行的对文档库或列表进行添加、修改，在列表项的作者或修改人都会是系统帐户，而不是当前登录那个人的帐户，除非当前登录的人是网站集的管理员。
因为，SPSecurity.RunWithElevatedPrivileges 是通过模拟一个固定的帐户去进行操作，所以就带来了另一个问题，就是当这“代理人”系统帐户对列表或文档没有权限的时候，就像上图那样，系统帐户对列表的权限是受限访问，SPSecurity.RunWithElevatedPrivileges 就会不起作用，而且在代码的层面上很难发现这个问题。所以在需要通过调用SPSecurity.RunWithElevatedPrivileges来提升权限操作的列表或文档库，都需要确保系统帐户(SHAREPOINT\system)在该列表或文档库中存在，并且这个帐户的权限必须为完全控制。
这样调用提升权限时才会成功。