企业文件服务器是一个集中的存储位置或工作空间,允许连接设备上的员工协作文件和文件夹。迁移文件服务器到其他位置有几个原因。本文重点介绍支持远程和移动工作者的原因。
企业文件服务器是一个集中存储或工作空间,允许连接设备(笔记本电脑、PC、平板电脑甚至手机)的员工访问文件和文件夹,并为日常协作的业务相关任务建立工作流程。术语“文件服务器”通常仅限于通过本地网络访问。自2006年以来,随着AWS和Amazon S3的出现,以及Box、Dropbox、Google Drive和OneDrive等各种文件同步和共享平台的出现,文件服务器的概念也进入了一个全新的云时代。大量的同步工具使文件服务器迁移(又名文件同步和共享)成为一个热门话题,因为人们意识到Dropbox和OneDrive确保了文件和文件夹始终与用户同步和可用。我们已经看到了文件服务器被淘汰和内容从文件服务器迁移到外部文件共享服务(如Dropbox和OneDrive)的迁移浪潮。其动机是使员工更加流动和高效。一些公司发现文件服务器迁移非常成功和有帮助,而其他公司却寄予厚望,还有一些公司甚至不想尝试迁移。那么,不同公司不同迁移经历的原因是什么呢?
严格来说,文件同步共享和文件服务器迁移是两个不同的概念。文件服务器迁移通常涉及将文件服务器从旧版本迁移到新版本,例如从Windows 2012迁移到Windows 2019,或者将物理文件服务器迁移到虚拟化环境或云环境,如VMWare或Azure Files。
由于本文侧重于支持远程和移动工作者,我们将把文件服务器迁移当作与文件同步和共享同义,并专注于最流行的选项——将文件服务器迁移到SharePoint和Azure文件。
许多公司发现将文件服务器迁移到Microsoft SharePoint非常成功且有帮助,而其他公司却不抱太大希望,甚至有些公司根本不想尝试迁移。那么,不同组织有不同迁移经历的原因是什么呢?在我们回答这个问题之前,让我们先来看看SharePoint的一些局限性。
根据SharePoint Online 文档:
“虽然 SharePoint Online 每个库可以存储 3000 万个文档,但为了获得最佳性能,我们建议跨所有文档库同步的文件不要超过 30 万个。此外,如果您同步的所有库中有 30 万个或更多项目,即使您没有同步这些库中的所有项目,也可能会出现同样的性能问题...”
然而,根据经验,性能在超过 10 万个项目后开始下降。奇怪的是,这个数字在 SharePoint 文档的其他上下文中也有提及。无论是 30 万还是 10 万,底线是在许多实际的企业环境中,随着文件数量的增加,OneDrive 同步客户端会出现严重的性能问题,因此用户最终不得不切换到 Web 界面。只有最小的组织和数据集最小的组织才能从映射驱动器的易用性中受益。
与 OneDrive 同步限制相比,库中5000 个视图项限制是一个更严重的问题。一旦库中的项目超过 5000 个,它几乎变得无法使用。
可能的解决方法
重新组织跨多个站点和库的数据,确保每个站点和库中的文件和文件夹不超过100,000个。如果OneDrive客户端连接到总项目超过300,000个的站点,请切换到网页界面,不要使用OneDrive同步。如果您的文件总数不多,这种解决方案是可以的。
这种限制是迁移文件共享到SharePoint Online时的另一个常见问题。它通常表现为以下错误:
“指定的文件或文件夹名称太长。所有文件和文件夹的URL路径必须是400个字符或更少(并且URL中任何单个文件或文件夹名称的字符数不得超过400)。请键入更短的文件或文件夹名称。”
任何不符合此要求的文件都会导致迁移失败。由于这是包含文档库完整路径和名称的相对URL的上限,因此这种情况发生得太频繁。结果就是迁移不完整或中断。
你可能遇到的另一个更严重的限制是,当用户将SharePoint Online文档库与他们的PC同步时,Windows PC上的256字符限制。错误消息可能如下所示:
“文件名对目标文件夹来说太长。您可以缩短文件名然后重试,或尝试使用路径较短的位置。”
可能的解决方法
使用可以自动缩短名称以满足要求的工具。这是一个可怕的变通方法,因为文件并没有被隔离。像Adobe InDesign或AutoCAD这样的常见文件类型都有从主文件到支持文件的链接文件。如果文件名被截断,文件捆绑包的完整性就无法保证。只有在您的文件是独立的情况下,才使用这种变通方法。
除了将文件服务器数据重新组织到不同的文档库中的不同存储区之外,重新组织权限也是一个主要的难题。
以下引用说明了为什么有些人认为SharePoint不支持打破权限继承,而其他人则指出它确实支持。这很令人困惑,因为支持确实存在,但仅限于相对较小的数据集。文档解释道:
“一个列表可以有多达3000万个项目,一个库可以有多达3000万个文件和文件夹。当一个列表、库或文件夹包含超过100,000个项目时,你不能在列表、库或文件夹上打破权限继承。也不能重新继承权限。然而,你仍然可以在该列表、库或文件夹内的各个项目上打破继承,直到列表或库中唯一权限的最大数量...”
这可能会将权限迁移和管理变成一个数据重组的噩梦,以避免手动打破列表、库或文件夹中元素的权限继承。
可能的解决方法
重新组织跨多个站点和库的数据,确保每个站点和库不超过100,000个文件和文件夹。当文件和文件夹重新组织时,重新设置文件夹和文件的权限。这不是一种变通方法,而是一种繁琐的数据迁移方式。
许多公司也发现将文件服务器迁移到 Microsoft Azure Files 很有帮助。这种迁移更为复杂,涉及到 Active Directory 同步以同步 Azure AD 身份信息,Azure File Sync 以将文件从本地文件服务器同步到 Azure 文件服务器,以及开放防火墙上的非 HTTP 和非 HTTPS 端口以允许文件传输。由于过程复杂和防火墙要求,Azure 文件迁移通常仅为计划将所有数字资产迁移到 Microsoft Azure 云的组织所保留。它也有其他优点,例如减少管理开销,但从支持远程和移动工作者的角度来看,与原始的本地配置相比并没有太大优势。
由于SharePoint与OneDrive紧密集成,而OneDrive采用了通用的文件同步和共享方法来传输文件,传统的驱动器映射功能被桌面上的同步文件夹所取代。许多业务流程和应用程序依赖于旧的驱动器映射方法。如果您的业务依赖于此类驱动器映射,那么SharePoint迁移可能不适合您。
由于SharePoint由Microsoft托管,并以多租户方式为多个组织服务,因此它有预定义的数据备份和恢复策略。如果您需要特殊的数据备份服务或高级的数据保留策略,您不能依赖SharePoint为您提供这些数据服务。
正如上述SharePoint的限制所记录的那样,成功的SharePoint迁移可能需要对数据仓库进行重组。然而,重组可能导致现有应用程序无法在SharePoint上运行。某些应用程序,如AutoCAD、SolidWorks和Adobe InDesign,可能无法在SharePoint上与文档一起工作。许多设计和建筑行业的公司发现迁移到SharePoint非常困难。
有时候文件需要存储在特定区域以符合规定。某些行业有自己的政策来管理数据访问和跟踪。如果您需要确切知道您的数据托管在哪里,保留文件访问历史的审计追踪,并且保持3到6年的数据保留期,那么SharePoint迁移对您来说并不是正确的解决方案。
数据集越大,迁移过程越复杂。耗时越长,过程中出错的可能性就越大,成本也越高。通常使用SharePoint迁移工具(SPMT)来迁移文件服务器到SharePoint。但SPMT经常会出现错误信息,要求您缩短文件名或将文件分散到不同的库中,这使得迁移过程变得更加复杂。