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 Completed

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 diff erent system? Are off -site backup procedures in place?

5 Are alerts defined for key problems and conditions? Who monitors the e -mail address these are sent to? Are beepers used? Has the alert system been tested?

6 Are jobs defined for common tasks? A re 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)?

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 th e 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 ti me 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, maste r).

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 Completed

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 a pplications 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 req uired 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 m iddle-tier system and any back -end systems been tested? Under load? Monitoring of connection pooling to assure proper operation?

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 tr ansactional 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) i s 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 Completed

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 ne eded? 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 we ll-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 ag ainst 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?

Presentation Layer Considerations (Continued)

8 Are the custom error messages for IIS set?

9 Is the appropriate lev el 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 appli cation 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 service s? b

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?

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 Completed

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 equipme nt 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?

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 rela ted to physical security?

General Business Considerations

Consideration Completed

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?

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 f ull-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 business-critical 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 e-commerce systems.

• MOF embraces the concept of IT operations providing business-focused service solutions through the use of well-defined 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

Resolution of deployment problems

Testing

Development/design

Transferring ownership to operations

Operations responsible for solution

Transfer of project documenta tion and developer

collateral

Logistics

Operations

User education

Closing the deploying phase

Project review

Customer sign-off

Close-out report

Deployment complete milestone

Program management

Development

Operations

Questions?