MSF Deployment Phase
MSF Deployment Phase Tasks
• Starting the deployment
• Going Live
• Stabilizing the deployment
• Transferring ownership to
operations
• Closing the deploying phase
Starting the deployment
• Starts after a live pilot, where the team uses the
equipment, software, and components inventory,
schedule, and information concepts that it will use once
the site is active.
• Team incorporates the information it learns from the
pilot into the deploying tasks, ensuring that all known
issues have been considered.
• Once development is complete, the team will review
and update the deployment plan, using information
learned during the testing cycles.
• Prior to going live, the team should review and step
through all recommended procedures, pilot test results,
and reports, checklists, or collateral that were provided
during the earlier phases.
Going Live
• At this point, the pilot has been tested
and the team and key stakeholders
have agreed on the acceptance criteria.
• Acceptance criteria might mandate that
all issues have been resolved, or that
the solution is ready for deployment
with the knowledge that some issues
might exist and will be resolved in later
versions.
• The team should review the checklists
for potential issues, and if all appears to
working properly, it is time to go live.
Going Live Tasks
• Transitioning to Deployment
• Deploying the Site
• Architectural Considerations
Checklists
• Other Considerations Checklists
Transitioning to Deployment –
Logistic Manager Checklist
• The deployment strategy is reviewed and approved.
• Setup, installation, configuration, test, and operation
and support procedures are available, reviewed, and
approved.
• Deployment procedures are documented, reviewed, and
approved.
• Hardware and software components are available and
tested.
• The deployment team has clearly defined roles, and the
assigned personnel are trained and available.
• The project schedule has been reviewed and approved.
• There is a plan and ample resources for ownership
transfer to the operations team.
Transitioning to Deployment
Considerations
• It is vital that the project team continues to monitor the
site after deployment until the transfer of ownership is
finalized; This allows the team to establish baseline
performance records to determine whether performance
is going up or down.
• Neither testing nor live pilots can completely reproduce
the type of use and amount of load that the servers will
experience after going live.
• If the stress and capacity tests are performed well, the
team should have both test scripts and test results
available providing the baselines.
• It is important to compare the baseline numbers to the
new numbers any time a change is made to the servers,
visualizing what effects the change has on performance.
• Monitoring will continue on a regular basis, even after
ownership is transferred to operations.
Deploying The Sight
• The team makes the decision to deploy
only after reviewing the test results and
information gained by using checklists.
• Reviewing the checklists will alert the
team to any issues that may influence
the deployment.
• If your team finds itself investigating
the how and why behind a specific
consideration, it probably indicates that
the project is not ready to move
forward.
Architectural Considerations
Checklists
• Database Tier Considerations
• Application and Business Layer
Considerations
• Presentation Layer Considerations
Database Tier Considerations
Consideration
1
Were database statistics updated prior to launch? Are database indexes
fragmented? At what period will this be checked again, and corrected, if
necessary?
2
Have all COM components been registered on their servers? Has the
system run for long periods without failure or system resource issues?
3
Did the team define, test, schedule, and sign off on maintenance plans?
4
Are database backups tested and online? Has restoration been tested on
the same computer and on a different system? Are off-site backup
procedures in place?
5
Are alerts defined for key problems and conditions? Who monitors the email address these are sent to? Are beepers used? Has the alert system
been tested?
6
Are jobs defined for common tasks? Are roles assigned for emergency
situations? Has a lead been defined for incident handling?
7
Has the latest build of the database from your development/QA
environment to operations been migrated, installed, tested, and verified?
8
Has database security been addressed with appropriate logon accounts
created? Is the system administrator’s (SA) accounts password blank? Are
applications using the SA account or other account(s)?
Completed
Database Tier Considerations
(Continued)
9
Have all relevant service packs been loaded to the operations databases?
Are the OS and installed service pack level well known and documented in
case of failure and the manufacturer support is required to be called in?
Are security bulletins being maintained and monitored?
10
Has clustering failover been tested in the operations environment? How
long does the failover take to complete? Are all key decision makers
aware of the time needed to failover?
11
Has the operations’ database been loaded with clean data and have initial
inventory levels been set? Have feeds from other systems been verified
under load to ensure that system availability is unaffected at the time
they run?
12
Is there a backup of the operations database as it stands the day before
launch? Is it well known where this is stored?
13
Were data loads tested against the operations system? At what level (2x,
4x, 10x normal load)?
14
Has a disaster recovery plan (DRP) been established that includes
database procedures? Who is the DRP team leader? Is the leader’s
contact information well known, and is a contingency leader appointed?
15
Has a time increment been established for the transaction log dumping
that will be sufficient to recover activity to the satisfaction of the
business? Has it been tested?
16
Have backup power systems been fully tested (fire drill) to ensure proper
operation?
17
Are an appropriate number of replacement hard disks on hand in case of
failure in an array?
Database Tier Considerations
(Continued)
18
Are the default client connection network library settings established on
the server (typically: TCP/IP)?
19
Are all Database Application Server installation settings documented (sort
orders, default language, and so on)?
20
Is the database running on the default port of 1433? If so, can this be
changed to another port or ports to enhance security of the application
without affecting proper operation? If so, change it.
21
Are ancillary, non-essential SQL Server services running (MS Search,
OLAP)? Stop them if not required.
22
Are databases installed on the server that are not being used? Remove
them (pubs, Northwind, and so on—be careful not to delete system
databases like model, tempdb, master).
23
Are sufficient client access licenses and connections installed for the
database server and the OS? Are these being monitored to assure that
they do not reach their limit?
24
Is the database correctly tuned, and does it have the proper memory
usage settings applied?
25
Is the database set for Auto Growth? Is disk space sufficient for the
expected size of the data for 6-12 months ahead?
Application and Business Layer
Considerations
Considerations
1
Has the golden release of your applications and components been given a
release number, been archived, and deployed?
2
Were all required environmental settings for the applications set and
documented?
3
Were the proper security settings for the applications set and
documented?
4
Were the appropriate service packs for the environment applied and
documented?
5
Are all third-party software or components that are required by the
system installed and documented (version numbers, vendor contact
information, and so on)?
6
Are all the required DSNs for the applications defined and tested (correct
net library settings are being used)?
7
Has connectivity between the middle-tier system and any back-end
systems been tested? Under load? Monitoring of connection pooling to
assure proper operation?
Completed
Application and Business Layer
Considerations (Continued)
8
Are operations configurations for this tier backed up? Were scripts created
to reset configurations in an emergency, or to bring up a new server? Are
they in a well-known location?
9
Are the activation types for your COM+ application set properly? Has the
application been tested with the consoles logged on and logged off to
assure the proper identity is used? Have bogus transactional calls been
attempted to simulate rollback integrity?
10
Are the queuing settings for your COM+ application set? Have calls into
the queue been monitored through the cycle to assure they clear?
11
Are you sure that no active debug code or logging exists in the operations
components?
12
Has debugging in the COM+ application properties window been turned
off?
Application and Business Layer
Considerations (Continued)
13
Has server communication between servers been checked to assure
proper DNS resolution and routing (in case of multiple NICs) is
happening?
14
Are spare disk drives and NICs available on-site?
15
Has security logging been implemented, has impact on the system been
assessed?
16
Have all non-essential services and open ports on the server been
identified and closed?
17
Have any and all event log messages been identified and investigated?
Presentation Layer
Considerations
Considerations
1
Are the IIS server properties configured? Is a script available and stored
in a well-known place to reset the application settings or to bring up a
new server?
2
Have the secure socket layer (SSL) tokens been applied, as needed? Are
the tokens backed up onto portable media and stored in a well-known
place for emergencies or new server configuration?
3
Are any certificates that might be required loaded? Are the certificates
backed up onto portable media and stored in a well-known place for
emergencies, or new server configuration?
4
Has the latest release of the ASP code, images, and HTML files been given
a release number, been archived, and deployed?
5
Was an external connection used when testing the application against the
operations system? The external connection would be similar to what a
customer will use.
6
Are the appropriate DSNs for the ASP code set up and tested?
7
Have the unnecessary ISAPI filters been removed?
Completed
Presentation Layer
Considerations (Continued)
8
Are the custom error messages for IIS set?
9
Is the appropriate level of directory security set?
10
Are the performance tuning properties for IIS set, documented
(preferably scripted), and stored in a well-known place?
11
Are the appropriate operators for the server set?
12
Are the execution permissions and application protection levels set?
13
Have you enabled/disabled application logging, as required?
14
Does the OS have sufficient client access licenses for the expected peak
traffic loads?
15
Have you checked your Personalization & Membership settings and
assured that they are appropriate for your solution? Is the LDAP required
to be accessible to the public? If not, is it blocked at the firewall? Is
Anonymous access to the LDAP disabled?
Presentation Layer
Considerations (Continued)
16
Has the team checked the LDAP settings for its LDAP services?
17
Has the team loaded the appropriate P&M schema settings for its solution
in P&M?
18
Has the team mapped its Web servers to the proper P&M instance?
19
Has the team loaded the appropriate Site Server pipeline components
onto its servers and the related pipeline configuration files? Are
permissions on these files (as well as any .csc files) set so that users
cannot download these files? Were all .csc and .pcf files (and dependent
vbs scripts) examined to assure that they contain no clear text credentials
for servers or databases?
20
Has the team set the default pipeline component settings?
b
Presentation Layer
Considerations (Continued)
21
Has the team installed the proper scriptors (see #18 for security
considerations) for its pipelines, if it is using them?
22
Has the team applied all metabase or registry settings required to
improve the performance?
23
Have all non-essential Web server instances been disabled and/or
removed from the IIS application?
24
Have all non-essential SMTP server instances been disabled and/or
removed from the IIS application?
25
Have all non-essential FTP server instances been disabled and/or removed
from the IIS application?
26
Will the IIS Web-based administration be used? If not, disable or remove
it from the Web server configuration.
27
Are any IIS samples present on the server, or any other manufacturer
sample code? Remove them prior to launch.
Overall Considerations
• General Technical Considerations
• General Business Considerations
General Technical Considerations
Considerations
1
Has the team removed “Guest” accounts from the system and checked to
ensure that this does not affect the application?
2
Has the team double-checked the operations network infrastructure
against the architecture?
3
Has the team confirmed that no network equipment is in test or debug
mode (such as routers, switches, hubs, load balancers, and so on)?
4
Has the team properly configured caching engines with the proper
information?
5
Has the team applied any required operating system service packs and
documented the OS version and service pack level accordingly?
6
Has the team tested operations integration with third-party systems (such
as credit card systems, fulfillment, tax, and shipping)?
7
Has the team finalized training of the operations teams?
Completed
General Technical Considerations
(Continued)
8
Has the team finalized the operational processes and guidelines?
9
Has the team limited access to anonymous users to appropriate content
on the site?
10
Has the team developed, tested, and simulated disaster recovery
procedures? Are the appropriate lead roles assigned to individuals or
project positions?
11
Has the team created a backup of the operations code, data, and content
and moved it off site?
12
Has the team tested backup power systems and assured they are online
and fully charged?
13
Has the team defined security responses for denial of service, intrusion
discovery, and hacker attempts?
14
Has the team tested the operations server farms for response to the
removal or addition of servers?
15
Has the team considered issues related to physical security?
General Business Considerations
Consideration
1
Has the team completed full loop testing (actually placed an order,
received it, and inspected its accuracy)?
2
Has the team tested the returns process (actually returned an ordered
item)?
3
Has the team verified credit card charges and refunds?
4
Has the team reviewed integration with the accounting system?
5
Has the team tested backorder processing?
6
Does the team have procedures for contacting key decision makers in the
event of a major problem or security threat?
Completed
General Business Considerations
(Continued)
7
Does the team have internal controls in place for securing credit card
information?
8
Does the team have a clear understanding of promotional plans affecting
the launch and how they impact the site?
9
Does the team have a rolling 90-day marketing and promotion plan so
that operations is able to prepare for traffic spikes?
10
Has the team put in place change-control procedures for the operations
environment?
11
Does the team have a plan for quick-fix engineering in the event of a
problem during the launch period?
12
Has the team considered doing a soft launch before the full-fledged site
launch?
Stabilizing the Deployment
• A joint venture between the project and the
operations teams.
• Usually begins in the later part of the
developing phase and continues throughout
the deploying phase.
• Important to include time in the master
schedule for stabilizing because it gives both
teams an opportunity to fine-tune the
solution, resolves any issues that might arise,
monitors the site to ensure it continues to
work properly after going live, and assists the
operations team after the transfer of
ownership.
Transferring Ownership to
Operations
•
•
•
•
•
•
•
•
Transferring the Site
Project Team Tasks
Operations Tasks
Maintaining the Solution
Site Content Changes
Daily Site Management
Upgrading the Site
Microsoft Operations Framework
Transferring the Site
• The project team will be closing
any open issues and handing off
maintenance activities to the
operations team.
• The operations team will be
opening procedures and validating
all collateral and equipment
received from the project team.
Project Team Tasks
• Verifying that the operations team has the
proper resources to maintain and manage the
new site.
• Confirming that the knowledge base for
transfer to the operations team is finalized.
• Reviewing operations’ logbooks and ensuring
that the procedures are being properly
performed; The developer should clarify and
correct any irregularities that were logged,
and ensure that these activities are being
maintained and monitored on a daily basis.
• Confirming that all project sign-off affidavits
are correct.
Operations Tasks
• Activate all reporting systems.
• Validate and publish all collateral.
• Validate and publish the
knowledge and databases.
• Review training materials provided
by the project team.
Maintaining the Solution
• Important that operations personnel
monitor the site on a continual basis.
• Allows the team to remain proactive,
avoiding issues before they occur.
• Most important aspect of the team’s job
is to ensure that the site’s businesscritical environment is available seven
days per week, 24 hours per day.
Site Content Changes
• Operations team manages and
maintains site content on a daily
basis.
• Several tools are available to track
and upgrade the site’s content.
Daily Site Management
• Testing all system changes, including service packs, newly
tested drivers, or newer versions of hardware and software as
they are introduced to the environment.
• Confirming that the solution’s capacity is monitored on a daily
basis, and installing additional boxes if they are required.
• Reviewing critical diagnostic messages as they are identified.
The team will provide immediate relief to any critical error
messages.
• Monitoring the system’s recoverability. Should something fail,
the team may use third-party tools to identify and correct
these issues.
• Validating data integrity on a daily basis; this will make sure
nothing is corrupted because of memory or program failures.
• Implementing daily checks on the site, making sure it
responds properly.
Daily Site Management
(Continued)
• Determining and logging any issues that occur on a daily
basis.
• Ensuring appropriately controlled release and change
management, and accurate inventory tracking of all IT
services and systems.
• Managing physical environments and infrastructure tools,
balancing cost with technology and business needs.
• Ensuring quality customer support, quick problem resolution,
and dedicated ownership of service level management.
• Ensuring predictable, repeatable, and automated day-to-day
system management.
• Ensuring careful protection of corporate assets by controlled
authorization to systems and information.
• Ensuring dedicated management of external support and
services provided through partners and outsource vendors.
Upgrading the Site
• If the site needs extensive add-in information or if the
architecture or design needs upgrading, the product
planning or marketing personnel might choose to
initiate a new or second version project.
• No matter how the initial project was deployed, the
second version would be deployed by establishing a
development, testing, and staging environment that is
transferred to production after successful testing and
initiating a live pilot.
• Although it is possible to manually install the operating
system on the servers, using a cloning process like
Sysprep.exe is an easy and efficient way to deploy the
operating systems on new servers.
Microsoft Operations Framework
• MOF recognizes that current industry best practice for IT
service management has been well documented within the
Central Computer and Telecommunications Agency’s (CCTA) IT
Infrastructure Library (ITIL).
• MOF combines these collaborative industry standards with
specific guidelines for using Microsoft products and
technologies.
• MOF also extends ITIL code of practice to support distributed
IT environments and current industry trends, such as
application hosting and Web-based transactional and ecommerce systems.
• MOF embraces the concept of IT operations providing
business-focused service solutions through the use of welldefined service management functions, which provide
consistent policies, procedures, standards, and best practices
that can be applied across the entire suite of service solutions
found in today’s IT environments.
Closing the Deployment Phase
• Signing Off on the Project
• Obtaining Customer Sign-off
• Producing the Closeout Report
• Conducting the Project Review
Signing off on the Project
• Once all the deploying tasks are
complete, the team must formally agree
that the project has reached the
deployment complete milestone and
that the project’s work is finished.
• By approving the milestone, team
members signify that they are satisfied
with the work performed in their areas
of responsibility.
Obtaining Customer Sign-off
• Upon project closure, the product
manager obtains the final sign-off from
a representative of the customer,
signaling approval of the solution and
permission for the team to disengage
from the project.
• Although, at this point, the team is busy
informally closing outstanding tasks and
wrapping up deployment, the sign-off
should be a formal acknowledgement
that the project is complete.
Producing the Closeout Report
• Final versions of all the major
project deliverables (for example,
vision/scope document)
• User information summary
• Project review meeting summary
• Sign-off by the team
• Sign-off by the customer
• Summary of next known steps
Conducting the Project Review
• When the project is complete, the team should
hold a review meeting to discuss the project
and identify what went well, what didn’t go
well, what to replicate in future projects, and
what to change.
• Without assigning blame, team members
conduct the project review with the goals of
learning from mistakes and improving future
projects.
• Often called a postmortem, the project review
meeting sometimes takes place shortly before
the end of the project rather than afterwards,
because team members might be required to
leave the project before it ends.
MSF Deployment Summary
Key Tasks
Deliverables
Owners
Starting the
deployment
Updated deployment plan
Logistics
Going live
Commerce site connected to the Internet
Logistics
Stabilizing the
deployment
Optimized hardware and software
Testing
Resolution of deployment problems
Development/design
Transferring
ownership to
operations
Operations responsible for solution
Logistics
Transfer of project documentation and developer
collateral
Operations
Closing the deploying Project review
phase
Customer sign-off
Close-out report
Deployment complete milestone
User education
Program management
Development
Operations
Questions?