Before
deploying the Microsoft Outlook client, organizations should carefully
evaluate their messaging needs and take a good look at their existing
environment. There are many facets to the deployment of any software
solution, and organizations with complex environments and messaging
needs will only be successful in their implementation if they plan
accordingly.
Identifying and
documenting various client needs, reviewing the overall network
topology, and reviewing recommended best practices can allow
administrators to greatly enhance the performance of each deployment and
ensure a transparent client installation.
Network Topology Bandwidth Consideration
When planning the
deployment of Outlook clients to end users, administrators should take
their existing network environment into account to avoid network
disruptions or bandwidth saturation that could impact their user
community.
When evaluating the
network environment in a single-site deployment, the primary focus
should be on ensuring adequate bandwidth for the client deployment. By
planning the deployment in small groups, or after normal business hours,
administrators can avoid negatively impacting their user community.
With multisite
organizations, administrators must review the available network
bandwidth on wide area network (WAN) links. Because these types of
connections are generally significantly slower than local area network
(LAN) connections, it can be challenging to deploy multiple Outlook
clients simultaneously without negatively impacting the overall WAN
performance. If this is done during normal working hours, or during
periods of high network utilization (during the evenings when network
backups are being performed, for example), communication problems can
result.
One way to avoid
passing large amounts of data across the WAN is through the use of
administrative distribution points that contain copies of the files
necessary for installation. By placing an administrative distribution
point at each remote location, deployments can be managed centrally
while minimizing the traffic across the WAN link. This can help avoid
bandwidth saturation and can improve overall implementation times.
Planning Best Practices
To assist in the planning process when deploying the Outlook client, the following best practices are offered for review:
Deploy the
Outlook client with the Microsoft Office suite to provide enhanced
functionality, such as the ability to utilize Microsoft Word as the
Outlook client email editor.
Be sure to document all profile settings and configuration options for each transform, PRF, and custom installation file.
Always test deployment options and profile generations in a lab environment prior to deploying to actual clients.
Deploy
Outlook and preconfigured settings to a pilot group prior to full
deployment. Administrators should work with these pilot users on testing
all aspects of the application prior to widespread distribution.
Break
users into small, easily managed groups for deployment. Deploy the
client software in phases to these groups to ensure “morning-after”
supportability.
When
creating and naming configuration files, use unique naming conventions
based on the group or configuration options being focused on. For
example, when configuring options for workstations in the Public
Relations department, you can name the file public_relations.prf to
avoid confusing it with other configuration files.
Addressing Remote and Mobile Client Systems
When planning
the Outlook client deployment, special attention must be paid to the
needs of remote and mobile clients. With remote and mobile users
accessing the business network environment using many different methods,
administrators should consider what might happen to clients who access
the network over low-bandwidth links, such as virtual private network
(VPN) or Remote Access Server (RAS) dial-up links.
One method to avoid
this problem is to schedule remote and mobile users to come to a
location where administrators can perform the installation manually.
This can be accomplished during monthly or quarterly meetings or during
sales calls near a corporate office. Alternatively, user workstations
can be shipped to a central location where administrators can install
the application and return the machine to the user. This method is often
used during full software upgrades, or in situations where the
installation process requires special know-how beyond the average end
user.
As an
additional alternative, rarely used except with senior executives,
administrators can travel to the client location to perform the needed
work.
Managing the Outlook Deployment
Managing the deployment of
Outlook clients can be much easier when utilizing a software deployment
tool, such as Microsoft System Center Configuration Manager 2007 (SCCM).
With Microsoft SCCM, deployments can be tracked and managed down to the
desktop level. Administrators can identify which desktops need the
Outlook client, deploy the Outlook client, and even identify and track
any failed installations utilizing the reporting functionality built in
to SCCM 2007.
When options such as SCCM
are not available, it can be extremely difficult to track the deployment
of the client and determine overall progress. The tools available in
the ORK do not present any evidence on the installation progress, nor
does the use of Windows 2003 or Windows Server 2008 Group Policy. However, you can use the following methods to gather a limited amount of information:
When using
Windows Server Group Policy, administrators can filter the server
Application Event Logs to search for any events generated by the MSI
Installer.
On the
local machine, administrators can use the Add or Remove Programs
application in Control Panel to determine if the Outlook update package
is listed. By utilizing the Remote Desktop feature built in to Windows
Vista, this option can be accomplished remotely.
