9 Points to

Consider
Before You Implement SharePoint
So you’re sold on the idea of using SharePoint in your office. There are many factors to consider when implementing a
SharePoint platform that’s optimized for your company. Taking the time to address each factor will help ensure your portal
performs well and is easily scalable. When implementing SharePoint, you need to consider the following 9 points.

1. Choosing the SharePoint version that best

meets your needs
Determining which SharePoint version to purchase can be a little confusing, so I’ll summarize the key features of each version.
Windows SharePoint Services (WSS) 3.0, a free download for users who have Windows Server 2008 or Windows Server 2003,
is a fully functioning portal. It includes the Standard Site Templates and Web Parts and integration with Microsoft Office 2007.
Search Server 2008 Express provides enterprise search capabilities for users of WSS 3.0 without requiring them to purchase the
full version of MOSS 2007. Office Forms Server 2007 lets users deploy forms created in Office InfoPath 2007 (available sepa-
rately) on a SharePoint portal site and centrally manage those forms using Office InfoPath Forms Services. MOSS 2007 with
the Standard CAL includes everything in WSS 3.0 and Search Server 2008 Express, plus Site Directory, Site Manager, Social Net-
working Web Parts, RSS feeds, user profiles and the Profile Store, audience targeting, Document Management Site Templates,
Enterprise Site Templates, integration with Microsoft Information Rights Management, and single sign-on (SSO). MOSS 2007
with the Enterprise CAL includes everything in MOSS 2007 with the Standard CAL, plus business intelligence (BI) features.

2. The size of your first portal

It’s often difficult to predict how a SharePoint portal will be used. You might have grand plans for the portal only to find out
that it gains little acceptance. Conversely, you might anticipate that it really won’t catch on only to find extremely heavy traffic,
with the portal struggling to keep up with the demand. In my experience, the best implementations start off small and grow
as needed. The development cycle is a little different for portals because most items can be quickly changed and modified.
For that reason, I strongly suggest using a prototype approach for any SharePoint project, regardless of the portal’s ultimate
size. Create a few sites, obtain feedback from users, make the necessary modifications, and repeat.

3. Whether you want to use a 32-bit or 64-bit platform

Unless you have a compelling reason to install 32-bit SharePoint servers, consider using an x64 platform for both the front-
end and back-end database servers. If you plan to integrate BI with your portal, you might need to install a 32-bit server for
compatibility. For example, Microsoft Dynamics GP requires a 32-bit SharePoint server to integrate BI into a SharePoint site.
However, x64 support is planned in the future. One primary benefit of an x64 platform is scalability. With the 32-bit platform
and the standard edition of Server 2008 or Windows 2003, you can address only 4GB of memory. With an x64 platform and
the standard edition of Server 2008 or Windows 2003, you can address 32GB of memory.

4. Whether you want to use virtualization

Virtualization lets you run multiple virtual servers on a single hardware host. For a small single front-end/back-end Share-
Point server farm, virtualization is a good solution because of reduced hardware costs and better fault tolerance, but what
about large installations? Virtualization of large SharePoint farms is also possible.

TM

ADVERTISING SUPPLEMENT SPONSORED BY

www.mimosasystems.com
5. Whether you need a high-availability solution
If your SharePoint farm must be highly available, consider either Microsoft or VMware clusters. Clusters typically involve shared
storage on a SAN with two or more cluster nodes. Clusters are designed to automatically fail over to a different host in the
event of a hardware failure. Microsoft clusters are typically single-application clusters, such as a Microsoft Exchange or SQL
Server cluster. VMware clusters often are multiple-application clusters, where different applications reside on the same cluster.
VMware clusters offer better granular failover capabilities compared to using Microsoft clusters.

6. How you want to configure your Microsoft

SharePoint farm
Many factors must be considered when designing the optimal SharePoint farm configuration for your company’s SharePoint
portal; for example, anticipated traffic from the Internet, the need for dedicated servers for SharePoint roles, and the need for
more than one database server. One of the most common SharePoint farm designs is a single back-end SQL Server database
server with a single front-end server. The front-end server manages the areas of central administration, web services, document
conversions, Excel calculation services, searches, and incoming email.

7. How you want to back up your Microsoft

SharePoint platform
If you’re using a SQL Server backup agent, you can somewhat protect a SharePoint installation by either backing up the SQL
Server database or dumping the SQL Server database to a file that later gets saved offline. You should back up all the other
servers in your SharePoint farm as well. For larger environments that use a SAN, you can take snapshots of the SAN and save
them to Just a Bunch of Disks (JBOD) to get around backup time constraints. However, online backups are vulnerable to virus
outbreaks and other malware attacks that can potentially leave them useless, so it’s important that you copy the snapshot
backups to some type of offline media as well.

8. How you want to restore your SharePoint platform if a di-

saster strikes
If you work for a publicly traded company that must be Sarbanes-Oxley (SOX) compliant, it’s important to prove that you
can recover from a disaster and prove how quickly you can recover. If you’ve had the unfortunate experience of recovering
your SharePoint site after a major hardware failure or disaster, you know it can be challenging. Running a multiserver farm
only complicates the restore process. There are two major advantages when using virtualization for disaster recovery: There’s
significantly less administrator involvement during the restore process, and restoring to different host hardware doesn’t
complicate the process.

9. What approach should you take for SharePoint

Recovery, Retention, and eDiscovery?
Any data that resides on your SharePoint portal could potentially be requested in an eDiscovery request. Administrators
need to ensure that the right amount of data is protected and preserved regardless of what the end user does. In more
detail, a subset of the information contained within MOSS, such as an employment contract, may be subject to record reten-
tion regulations or be requested as part of an electronic discovery matter, forcing IT organizations to retain it for a specified
period of time. Your archiving system should allow you not to only capture all the content you need, but also allow you to
define granular policies to retain data for the amount of time you need. The eDiscovery application should not leverage the
SharePoint index to reduce the performance degradation eDiscovery searches create on the SharePoint farm if they do. Your
recovery application should not only cover you for the recovery of a farm, but allow you to perform full-fidelity fine grain
recovery without the need for a recovery farm. This means that not only the item can be restored but that all of the metadata
that is tied to that item is recovered.

TM

ADVERTISING SUPPLEMENT SPONSORED BY

www.mimosasystems.com