Jcpenney: Standard Operating Procedures

JCPenney
Standard Operating Procedures

Software Deployment and Packaging
A comprehensive guide on the Software Packaging and Deployment process

followed by the SPAD Team.
JCPenney 1
Standard Operating Procedures SPAD Team
© Copyright and Trademarks
Copyright © 2019, J. C. Penney Services India Private Limited
This literature is confidential and proprietary to J. C. Penney Services India Private Limited
(JCPSI). It may not be photocopied, reproduced, published, disclosed, and conveyed to
another party without prior authorization from an authorized representative of JCPSI.
This policy shall supersede all other earlier policies/rules on the subject matter and shall
come into force with effect from the abovementioned date. Management reserves the right
to amend /alter/modify/cancel this policy with or without due and adequate notice.
JCPenney is a registered trademark of JCPenney. Other names may be trademarks of their

respective owners.
JCPenney 2
Contents
1. Introduction ........................................................................................................................ 1
1.1 Understanding SCCM ............................................................................................................................. 1
2. Scope ................................................................................................................................... 3
3. Team Organization ............................................................................................................. 4
3.1 Stakeholders............................................................................................................................................... 4
3.2 Functional Requirements ...................................................................................................................... 6
4. SCCM Monitored Infrastructure ....................................................................................... 8
5. Repackaging Process ....................................................................................................... 10
5.1 Requirement Gathering ...................................................................................................................... 10
5.2 Validation ................................................................................................................................................. 11
5.3 Repackaging............................................................................................................................................ 11
5.4 User Acceptance Testing .................................................................................................................... 15
6. Deployment ...................................................................................................................... 16
6.1 Stores Packaging and Deployment ................................................................................................ 16
6.2 Non-Stores .............................................................................................................................................. 22
6.3 Third-party Application ....................................................................................................................... 22
7. Patching Process .............................................................................................................. 23
7.1 Non-Stores .............................................................................................................................................. 23
7.2 Stores ......................................................................................................................................................... 25
8. Zero-day Patching ............................................................................................................ 28
9. SLAs ................................................................................................................................... 29
9.1 Compliance .............................................................................................................................................. 30
10. Reporting .......................................................................................................................... 31
11. Abbreviations ................................................................................................................... 33
12. Flow Charts ....................................................................................................................... 34
13. Associated Forms ............................................................................................................. 37
JCPenney 3
Change Log
Version No. Created by Reviewed by Approved by Remarks/Changes
SOP_SPAD_v1.0 Biju. K SPAD Team D. N. Naveen Kumar Initial Release
JCPenney i
1. Introduction
As a giant in the retail industry, JC Penney has a huge number of stores and support
offices located in different regions in the United States and India. This huge network of
computers that include servers, client machines, store registers and Data centers are
centrally managed using Microsoft System Center Configuration Manager (SCCM). The
health and operational status of all these systems are monitored using SCCM.
1.1 Understanding SCCM

System Center Configuration Manager (SCCM), a systems management product from
Microsoft, is an overall management solution for computers utilizing Microsoft Windows
operating systems. This enables IT professionals to manage the lifecycle of all Windows-
based device including:
 Packaging, deploying and maintaining systems and software
 Gather asset intelligence for inventory management
 Respond to security threats
SCCM supports almost all the recent editions of Microsoft Windows Server operating
systems and client OS like Windows 10, Windows 8.1, and Windows 7.
The SCCM infrastructure consists of multiple servers that stores images of operating
systems and software applications for further deployment to end-user machines. The
SCCM client application contains information on the hardware, software installation and
enables the automated installation of OS upgrades, security patches, and software
updates. A client-side application called “Software Center” enables the end-user to install
the required software updates at their convenience.
SCCM is generally customized to only collect the data required to support the
infrastructure in the environment. This information mainly includes:
 Hardware specifications, installed software applications, services, and peripherals.
 Security-related information
 Software upgrades and updates
 User Account (Local) and timestamps
The benefits offered to a client by Configuration Manager are as follows:
 Install software updates and patches with little to no interaction.
 Save time and productivity by performing the deployment and updating process
in the background.
JCPenney 1
 Provide flexibility to users by letting them choose a suitable time to install new
software or run maintenance on their device through self-service portals called
Software Center.
 Ensure security by remotely managing software patches, antivirus protection, and
firewalls.
 Ensure compliance with company standards and regulations.
JCPenney 2
2. Scope
The Software Packaging and Deployment Team (SPAD Team) is responsible for the asset
management, packaging and deployment of all software applications, security patches
and other LOB applications to all the machines present on the JC Penney environment.
These machines range from the servers and registers at the stores to the workstations
and laptops in support offices housed both at Bangalore and Plano.
The SPAD team is headed by the SPAD manager and the team consists of trained
engineers to perform the following functions:
 Gathering Asset Intelligence

 Perform software packaging and deployment
o Stores
o Non-stores
 Deploy Microsoft Security Patches
 Deploy IT Vulnerability Fix
 Reporting
 Handling ad-hoc projects, for example, application migration, etc.
JCPenney 3
3. Team Organization
3.1 Stakeholders
The stakeholders and teams that the SPAD usually interacts are as follows:
Team / Stakeholder Requirements Contact information

Wintel Operations For server reboots, Tech-OpsSupport-InfraSupport-Wintel-BGLR
and housekeeping
Infrastructure Escalations – L3 Bangalore:

Engineering SCCM related issues IT-InfraEng-BGLR-ALL-dl@jcp.com
De, Arnab- ade@jcp.com
Plano:
IT-InfraEng-PLANO-ALL-dl@jcp.com
Gleason, Blake- agleason@jcp.com
JCPenney 4
Wintel For maintenance IT-InfraEng-BGLR-ALL-dl@jcp.com
Infrastructure windows Gali, Devarajulu N - dgali@jcp.com
Engineering
Store Team Pre-deployment Store-Release-Status-dl@jcp.com
and Post
deployment
status for Stores
Home office  For non- IO-ITFO-Alliance -IO-ITFO-Alliance-dl@jcp.com>;

compliance support IO-ITFO-Atlanta - IO-ITFO-Atlanta-dl@jcp.com>;
 Application IO-ITFO-BuenaPark - IO-ITFO-BuenaPark-
deployment dl@jcp.com;
support IO-ITFO-CedarHill -IO-ITFO-CedarHill-
dl@jcp.com;
IO-ITFO-Columbus - IO-ITFO-Columbus-
dl@jcp.com;
IO-ITFO-Lathrop - IO-ITFO-Lathrop-dl@jcp.com;
IO-ITFO-Lenexa - IO-ITFO-Lenexa-dl@jcp.com;
IO-ITFO-Manchester -IO-ITFO-Manchester-
dl@jcp.com
IO-ITFO-Reno - IO-ITFO-Reno-DL@jcp.com
IO-ITFO-SaltLakeCity - IO-ITFO-SaltLakeCity-
dl@jcp.com
IO-ITFO-SpanishFork - IO-ITFO-SpanishFork-
dl@jcp.com
IO-ITFO-Statesville - IO-ITFO-Statesville-
dl@jcp.com
Kingsuk  For stores Chakrabarty, Kingsuk - kchakra2@jcp.com

Chakrabarty/ deployment Brackett, Shannon - swild7@jcp.com
Shannon Brackett schedule
Field IT  For remediation of To, Titan - tto@jcp.com
(Titan To/ IBOs S, Srikant - ss6@jcp.com
Srikant)
JCPenney 5
Table 1: Stores contact information

POS Team For package- Bangalore:
related concerns Naidu, Radhakrishna - rsgnaidu@jcp.com
and deployment Krishnamurthy, Amresh - akrish13@jcp.com
schedule
Plano:
Chakrabarty, Kingsuk - kchakra2@jcp.com
Valentine, Skip - svalent9@jcp.com
CPOS Team For package- Bangalore:
related concerns Chen, Fernando - fchen2@jcp.com
and deployment
schedule
PDA Team For package- Bangalore:

related concerns A, Rajeesh - radambil@jcp.com
and deployment
schedule Plano
Kolli, Venkata S - vskolli@jcp.com
SPS, MFE For package- Plano
related concerns Jeff Mullens - jmull5@jcp.com
and deployment Anusha, Devi - danusha@contractor.jcp.com
schedule
MPU For package- Plano

related concerns Cooper, Lynn L - llcooper@jcp.com
and deployment
schedule

3.2 Functional Requirements

The software requirements for a fully functional SPAD team are as follows:
 Server running System Center 2012 Configuration Manager

o Used to manage Windows Servers and endpoints in JCP environment
 Repackaging tool
o Flexera Admin Studio
 Third-party application patching tool
o Ivanti
JCPenney 6
 Remedy tool
o Used for creating work orders, change requests, ticketing, and other
associated request forms
 MS Office
o For communication and interaction between teams
 SharePoint
o Used to capture the store deployment calendar
 Test environment
o Repackaging VM
o Deployment testing VM
3.2.1.1 Supported Operating Systems

 Windows 10, Windows 7 and Windows 8.1
 Windows Server 2012, Windows Server 2008 and Windows Server 2016
3.2.1.2 Unsupported Operating Systems

 Non-Windows, for example, Macintosh and Linux/UNIX
JCPenney 7
4. SCCM Monitored Infrastructure

The company’s IT infrastructure is managed by two standalone SCCM servers running
System Center Configuration Manager, CB 1806 (upgrade in progress) located at
Bangalore and Plano respectively. Each server is assigned to monitor, provide packaging
and deployment services to endpoints in their respective sites. The SCCM also generates
reports to check the compliance of the endpoints and these reports are shared with
other teams and stakeholders for remediation and well-informed decision making.
The IT infrastructure and inventory are broadly classified into three categories:
 Stores environment- consists of Servers, Hyper-V servers, Store Leader Devices
(SLD) and registers
 Non-Store environment - consists of Servers, and workstations
 Other supported devices - UCCE
The following table will broadly outline the IT endpoints managed by each SCCM with
different operating system flavors associated with these assets. The numbers indicated
are likely to vary due to migration, closure of stores and addition of new machines.
Table 2: Infrastructure: Non-Stores
Non-stores Environment
Bangalore Endpoint 753
Bangalore Servers 37
IBO Servers 19
IBO Endpoints 436
US End Points 8762
Non-Store servers 1420
Supply Chain 70
SQL Server 154
UCCE (other supported devices) 40
Total 11691
JCPenney 8
Table 3: Infrastructure: Stores
Stores Environment
HYP Servers 1795
Store Registers 28603
Store Servers 1844
SLDs 1622
Total 33864
JCPenney 9
5. Repackaging Process
Repackaging is the process of capturing the changes made by an installation program
for the purpose of creating a new or a customized installation. This new installation is
called a “package”. It is designed to support the company’s standards and distribution
methods. The repackaging process is critical to the success of software roll-outs.
Repackaging saves time, effort, and money by allowing the system administrator to
customize installations to meet the standards set for software distribution within the
company. For instance, an administrator might repackage an application in order to
prevent all dialog boxes from appearing during the installation. This prevents the end-
user from making an incorrect choice and installing the application in an inconsistent
manner.
The general steps for repackaging an application are:
1. Requirement Gathering
2. Validation
3. Repackaging
4. User Acceptance Testing
5. Deployment
The flow chart for the repackaging process is attached as an appendix.
5.1 Requirement Gathering

As an initial step in a repackaging project, we share a package request form called Intake
form with the requestor. The requestor is required to fill the form and provide the source
information.
The sample intake form is placed as an appendix here.
A requestor should answer the following questions, which will be documented and used
further:
 Describe the application’s target users, and how the users typically use this
application.
 Describe how to install the application correctly with the options end users
require.
 The source and license information.
 Any other dependencies.
On submission of the intake form, the source files are copied to a designated share by
the requestor.
JCPenney 10
Input Intake form that is shared with the requestor
 Filled intake form

Output
 Source location of the application
5.2 Validation
This is the phase where the analysis of the application is carried out. All possible checks
are done to validate the application based on the gathered information in Requirement
Gathering phase.
Input Filled Intake form

Output Approved Intake form
Note: If we notice any discrepancies or if clarifications are required, the SPAD team will
reach out to the requestor to proceed further.
5.3 Repackaging
After validation, the SPAD team will repackage the application using one of the
repackaging tools. It also depends on the format of the source being provided.
The following flowchart explains the process or steps involved in repackaging an

application:
JCPenney 11
Repackaging may also include some scenarios like:
 Creating a “silent” installation that does not require end user interaction. This
involves suppressing the installation’s dialogs, so the installation runs unattended
with no progress indicators appearing on the user’s screen.
 Creating a “quiet” installation. Unlike a silent installation, a quiet installation
displays some type of installation progress indicator on the end user’s screen. This
lets users know that a process is running on their machine, so they don’t interrupt
while the package is installing
JCPenney 12
 Application source
Input
 Approved Intake form
 Repackaged Application i.e. msi/mst/wrapper,
Output
 Package release form
The repackaging process is performed using a third-party application called Flexera.
5.3.1.1 Package Unit Testing

This task involves the process of testing MSI packages on the target deployment
platform to ensure that the application works as expected. MSI packages must be tested
by both the packagers and the application users.
The tests listed below represent an organized script that a packager or tester can use to
verify that an MSI package functions correctly. The packager should perform most of
these tests on every package.
Table 4: Unit testing cases for repackaged application
Test Action Result
Install silently Msiexec /i <package> /qn No runtime errors

/L*v <log file>
Uninstall silently Msiexec /x {ProductCode} No runtime errors

/qn
MSI error log Review the Windows Installer log Install ends with result = 1
files for errors denotes success (result = 3
is a failure resulting in
rollback)
Install silently Msiexec /i … /qn No runtime errors
Self-Repair Break a KeyPath, launch No runtime errors

Application via advertised Shortcut
Launch all Initiate all shortcuts All shortcuts should launch

shortcuts successfully and allowed to
repair while it is launched
for the first time.
Directory table Check if the directory table is The product should be in

resolution evaluated to correctly locate the requested location and
product during the file copy. no unexpected folders exist
in the drive’s root folder.
JCPenney 13
Test Action Result
Property table Check if the property table is The installed registry should
resolution evaluated to correctly substitute contain resolved property
properties in the registry table. values where used.
Check starting of NT Services that are set to start No runtime or event log
NT Services have been started (If it has set to errors
auto-start, then a reboot will be
necessary)
Reboot check Perform a manual Reboot The machine starts up

without runtime or event
log errors
Automatic Ensure the product is not set to The product will not “auto
Updates automatically update itself update”
Basic Functionality If possible, test: New, Open, Save, No runtime or event log
Tests Save As, Help Contents, Help errors
About. Any additional tests that
the requestor has specified should
also be done here.
File Extension Launch or print a document No runtime or event log

Associations associated with your product errors, the application
should open or print the
document
Database If possible, database connectivity No database connectivity

Connectivity should be checked issues should appear
Common File If the application shares a The file extension should be

Extensions common extension then install handled correctly by the
both applications on the same remaining application and
machine, uninstall one and ensure not be ignored when it is
that the remaining package repairs activated.
when launched and continues to
service the file extension.
Lockdown Using a clean machine, install the No runtime or permission-

Desktop Test package, log out of Admin based errors. Any self-repair
account, log on as a User. Launch actions which may occur
the application. Repeat shortcuts must not fail.
and basic functionality tests.
JCPenney 14
Test Action Result
Uninstall It is not necessary to uninstall this “Clean” uninstall (No

silently; it just needs uninstalling. Application Pollution should
remain; Application
Documents and User Data
are allowed to remain)
NT Services are No runtime or event log

removed during errors
uninstall
5.3.1.2 QA Checks
In this phase, the repackaging team needs to verify the following:
 The created package functions as per the request.

 Check the basic functionality of the application. In some cases, this functionality
cannot be checked due to other constraints, for example, database connectivity.
 Check for a clean install and uninstallation of the application.
Note: These checks are manually performed without any SCCM intervention.
5.3.1.3 Pre-UAT Checks

In this phase, the application is deployed to the user’s machine for the user to carry out
the functionality checks to their satisfaction. The steps involved in the deployment of the
application to the test/user’s machine is as follows:
1. Importing an application/package to SCCM.

2. Deployment testing – installation, app launch, and app uninstallation
The user is notified on this deployment for UAT.
5.4 User Acceptance Testing

In this phase, the user will perform the desired functionality checks. After a successful
test, the user would mail the signoff to the SPAD team. On the receipt of the signoff, the
SPAD team can deploy the application to all the production machines.
JCPenney 15
6. Deployment
6.1 Stores Packaging and Deployment
The developer team uses the shared weblink -
http://fmcp211/SCCMPackageCheckout/SCCM/AddPackage - to generate a package
ID called check-out ID. The application owner develops the business application and
creates a package in SCCM console. The testing of the package will be on the test
prods at Plano by the application owner. The dev team notifies the TCOE team to
perform the next set of application and performance tests on servers and registers.
1. The SPAD team receives the mail from TCOE seeking the distribution of the
content to the Bangalore SCCM Server towards this. The SPAD team will deploy
the content to the test prods and registers.
2. The TCOE team will mail the SPAD team confirming the receipt of the latest
packages on the required machines.
3. Post the testing, the TCOE shares the results along with the sign-off to the
application owner. The package owner will connect with the Store leadership team
for the deployment schedule - for all the stores that include POS servers, NPOS
server and Registers.
4. On receiving the schedule, it is added to the deployment calendar by the SPAD
team.
5. The CRQs for this activity is raised by the package owner and the associated task
is assigned to the SPAD team.
6. The SPAD team is to deploy the package to the desired stores as per the calendar.
Note:
The SPAD team will communicate the package deployment to the Store release team
prior to the deployment.
Post deployment, the deployment status report will also be sent the store release
distribution list.
JCPenney 16
6.2 Non-Stores
Post the UAT phase in the repackaging process, after the signoff for the said application
is received, the application is deployed to all the required machines as per the
deployment plan.
6.3 Third-party Application

On receipt of a vulnerability alert for a particular third-party application from the ITSC
team, the SPAD will have to update the application. The steps to update the application
using Ivanti as follows:
1. Search and download the relevant application update.

2. Publish the application.
3. Synchronize the update to SCCM.
4. Test the update on a set of machines.
5. Create a CRQ, and then deploy the update to all the required machines.
JCPenney 22
7. Patching Process
7.1 Non-Stores
This section will detail the patching process of all the servers and endpoints related to
the non-stores’ environment of JCP. On the second-Tuesday of every month, Microsoft
will roll out the security patch KB and the ITSC team at JCP will share the validated KB
with the SPAD team on the second Wednesday of the month. On receipt of the security
KB, follow these steps:
1. The SPAD team will create a software Update Group (SUG) for Bangalore.
2. The testing for this patch should be done by selecting a few machines from the IT
team at Bangalore office. In this testing, the checks are carried out to confirm that
the patch is applied and post the reboot, check if the operating system and other
core applications work properly.
3. On Monday of the following week (3rd week), the patch needs to be deployed to
all Bangalore endpoints and servers. A standard CRQ is raised for all the Bangalore
endpoints followed by the patching for all the endpoints. Based on the client
policy, the endpoints are expected to reboot within 4 hours of the applied patch.
Note: We currently do not perform any testing before server patching due to lack of a
testing environment for servers.
4. A standard CRQ is also raised for all the Bangalore servers and patching on these
servers can be done from Monday through Friday during their maintenance
window- between 20:30 hrs. and 08:30 hrs. IST.
5. A standard CRQ is raised for the patching for all the IBO endpoints and it is
usually planned on Wednesday of the same week (3rd week).
6. After a standard CRQ is raised for all the IBO servers, they will be patched on the
same day within its planned maintenance window - between 2300 hrs. to 0400
hrs. IST. In case you encounter any issues, reach out to field IT (tto@jcp.com or
ss6@jcp.com) for any remediation.
7. After creating a standard CRQ for the patching for all the endpoints of Plano, it is
deployed on Friday of the same week (3rd week).
8. A single standard CRQ for patching of all the non-stores servers at Plano is
created. For patching these servers, view the policy on the SCCM console to know
all the 23 maintenance windows for the servers. Once the patching of the
Bangalore servers is complete, the team can deploy the patch to all the servers at
Plano as per the maintenance windows.
9. The patching of the servers associated with Supply Chain, SQL Server and Hyper-V
Server will be done with the "suppress reboot' setting applied. This will be
JCPenney 23
performed on the fourth week of the month. Each of these deployments will
require a separate CRQ.
Note: A total of nine CRQs will be raised during each patching process. Each CRQ will
be created on the required date and will be closed on the same day.
Based on the local client policy, the endpoints at Bangalore will be rebooted after four
hours, while the endpoints at Plano will reboot only after 24 hrs. For servers, the reboot
will be performed in their respective maintenance windows.
After each patching, a compliance report is generated to check if all the machines have
received the latest patch and to initiate any remediation in case of issues.
The flowchart for the patching process for the non-stores is attached as an appendix.
The different types of reports generated along with their purpose are as follows:
 A report – Lists the machines that are compliant.
 C report - Comprises the details that include the status of the machines like
reboot pending, etc.
For more information, see Reporting
Sample Deployment Schedule

The following table lists a sample deployment schedule. The dates used are only for
reference and easy understanding and it is likely to vary with each deployment. The
month chosen for this sample is July 2019.
Table 5: Deployment Schedule: Non-Stores
Suppress
Targeted group &
Week /Day Activity Reboot CRQ requirement
Time
required
Second wk. Receive KB
Wed
9 Jul
Second wk. Create a SUG A set of machines
Thu-Fri and perform pooled from the
(10 Jul – 12 testing of the Bangalore office
Jul) patch (1200 hrs. – 1600
hrs. IST)
Third wk. Patch all No Yes (Two CRQs -one for the
Bangalore
Mon servers and servers and one for
20:30 hrs. IST
15 Jul endpoints endpoints)
Third wk. Observation Period
Tues
JCPenney 24
Suppress
Targeted group &
Week /Day Activity Reboot CRQ requirement
Time
required
16 Jul
Third wk. Patch all IBO All locations Yes (Two CRQs -one for the
Wed endpoints 18 Servers and servers and one for
17 Jul and Servers 400 + endpoints endpoints)
(11 p.m. – 4 a.m.
CST for servers)
(maintenance
window)
no restrictions for
endpoints
Third wk. Observation Period
Thurs
18 July
Third wk. All endpoints Plano No Yes (Two CRQs -one for the
Fri and Servers Based on the servers and one for
19 Jul current endpoints)
maintenance
windows (23
different windows)
Fourth wk. Hyper-V Yes Yes
Mon server
Plano
22 Jul Supply chain Yes Yes
SQL Server Yes Yes
7.2 Stores
This section will detail the patching process of all the servers and endpoints related to
the Stores’ environment of JCP. On the second-Tuesday of every month, Microsoft will
roll out the security patch KB and the ITSC team at JCP will share the validated KB with
the SPAD team on the second Wednesday of the month. On receipt of the security KB,
follow these steps:
1. The SPAD team will create a software Update Group (SUG) for Bangalore.
2. An email seeking the details of the test store to perform the patch testing is sent
to the TCOE team.
3. On the assigned test store, the patch needs to be deployed. The status of the
deployment is shared with the TCOE team.
JCPenney 25
4. The application testing is performed by the TCOE team during the third week
(Monday through Friday) and a signoff for this patch is sent to the SPAD after a
successful test.
5. On the Monday of the fourth week, an email seeking the patching schedule is sent
to Kingsuk or Shannon.
6. On receipt of the deployment schedule, CRQs are created for each deployment.
Note: A total of 12 CRQs are created for the patching of all the Stores. One CRQ is
raised for each datacenter server and one for each datacenter register for a total of six
locations.
The flowchart for the store patching process is attached as an appendix.
Sample Deployment Schedule

Table 6; Deployment Schedule: Stores
Week/Day Activity Targeted group CRQ Communication

requirement
Second Receive KB Receive mail on the KB
wk.
Wed
(9 July)
Second Create a SUG and Test store Email to TCOE – Seeking a
wk. SEC package. Deploy allotted by TCOE test store
Thu- Fri the patch 1200 hrs. – 1400 Email to TCOE- Report of
(10 Jul– 12 hrs. IST the deployment. The
Jul) (2 hrs.) Turnover document with
security patch details is
shared by SPAD team to
TCOE.
Third wk. Application Testing Bangalore Sign off is provided by

Mon – Fri of the deployed TCOE.
(15 Jul – 19 patches by TCOE
Jul)
Fourth Seek Production Email sent to Kingsuk or
wk. Schedule Shannon seeking
(22 July) schedule
Tues- Await deployment Receive an email with the
Thurs schedule schedule
JCPenney 26
Week/Day Activity Targeted group CRQ Communication
requirement
(23 Jul – 25
Jul)
Fri Creation of CRQs Yes - Twelve
(26 Jul) CRQs
Fifth wk. Deployment of the Alpha Yes – 02 CRQs Pre-deployment schedule
Mon patch as per Beta Yes – 02 CRQs and post-deployment
(29 Jul) schedule Reno Yes – 02 CRQs status sent to store
(in some Lenexa Yes – 02 CRQs release DL.
scenarios, Columbus 1 Yes – 02 CRQs
first week Columbus 2 Yes – 02 CRQs
of the next
month)
JCPenney 27
8. Zero-day Patching
On the receipt of communication from the ITSC team on any vulnerability fix including
the KB or Common Vulnerabilities and Exposures (CVEs), the SPAD will follow the
standard process of testing the fix on a set of machines pooled from the Bangalore
endpoints. However, in this scenario, the zero-day CRQ will go for Change Advisory
Board (CAB) approval. The CRQ number will be shared with the ITSC team via email.
Post the CAB approval, the SPAD team will deploy the patch as per standard procedures
for patching of stores and non-stores.
JCPenney 28
9. SLAs
The Service Level Agreements (SLAs) for the services provided by the SPAD along with
the associated criteria is as follows:
Repackaging
Table 7: SLA Complexity Criteria
SL No. Complexity SLA (in Criteria to determine complexity

days)
 File addition or modification in package.
1 Simple 1  Registry additions or modifications in package
 Package containing 50 registries, 50 files
 Package Containing more than 50 - 200 registries or
50-400 files
 Packages contains com Add-ins
2 Medium 3  Packaging contains simple custom actions
 Package containing a service/ODBC entry
 Package required dependency check
 Package containing more than 250 files or 400 files
 Package includes complex custom actions
 Package which requires implementation for
3 Complex 4 conflict/compact ability issues
 Package containing more than one service/odbc dsn
 Package requires dependency check
Considerations:
1. The SLA mentioned for the repackaging considers only the requests in good
order.
2. The packager decides the application complexity based on the specified criteria
and needs to capture this information in the package release form.
3. The SLA duration starts when package is assigned to packager and ends while the
package is set for UAT. The SLA is inclusive of the time utilized for QA checks.
4. In case of any issues encountered and the package is put on hold, then the SLA in
such scenarios will be impacted. The SPAD team will notify the concerned
stakeholders with the justification.
5. The SLA hours will not cater for any delays in receiving any clarifications/changes
from the requestor. The SLA timing will be refreshed in case of any modifications
sought interim.
6. A day here refers to eight manhours during work timings.
JCPenney 29
9.1 Compliance
The following table lists the duration and the associated compliance percentage that the
SPAD team aims to achieve.
Table 8: Compliance Information
Compliance
Devices Target Date
Percentage
Workstations 95 % Second Monday (N+1)
Non-store Servers 100 % Second Monday (N+1)
Store Servers 100 % Third Monday (N+1)
Store Registers 98 % Third Monday (N+1)
Note: The letter N indicates the month of patching.
Considerations:
 These percentages are calculated for only the active machines.

 Multiple maintenance windows in place for servers
JCPenney 30
10. Reporting
The list of reports along with their description are listed in the following tables.
Standard Reports
Reports Description
Compliance 1 - Overall It provides the overall patch compliance status for a

compliance given software group (month wise)
States 1 - Enforcement states It provides detailed information of patch deployment

for a deployment states, for example, reboot pending status.
Status of a specified package This report will give you the status for the deployed
and program deployment package in Package Method.
All application deployments This report will give you advance level of deployment
(advanced) status for application in Application Method.
All application deployments This report will give you basic level of deployment
(Basic) status for application in Application Method.
Application compliance This report will give you application installation status.
Custom Reports
Reports Description
Overall Patch Compliance This report will give you the high-level patch report in
Dashboard-BLR-PLANO one dashboard.
Members of Local This report will give you a list of users who having Local
Administrator Group Admin Rights.
This report will provide you the list of machines on
List of Non-Clients by domain
which SCCM client is not installed based on domain.
Site Component Status This report will provide site component status in detail.
Client Health Statistics This report will provide the Client Health Status.
Site System Status This report will provide you the Site System Status.
This report will provide you the Overview of Site System

Site Status Overview
Status.
JCPenney 31
Reports Description
Complete System Hardware This report will provide you the detailed information of
Inventory Hardware Inventory.
Detailed System Health This report will provide you the details of Client Health
Report Status
Operating System Name and This report will provide you the machine list of OS
Count version and count.
JCPenney 32
11. Abbreviations
Abbreviation Description
9X Windows 95, Windows 98, Windows Me
ACE Application Consistency Evaluators
AR Application Request
ASD Application Supportability Document
COM Component Object Model
DLL Dynamic Link Library
GUID Globally Unique Identifier
HKCU HKEY_CURRENT_USER registry key
HKLM HKEY_LOCAL_MACHINE registry key
ICE Internal Consistency Evaluators
IRP InstallShield Re-packager Project
ISM Editor Project File
MSI Windows Installer
NT Windows NT 4.0, Windows 2000, Windows XP, Windows Vista
OS Operating System
Standard Something, such as a practice or a product, that is widely recognized or

employed, especially because of its excellence.
UI User Interface
UCCE Unified Contact Center Enterprise
JCPenney 33
12. Flow Charts

Application Re-packaging and Deployment Process
JCPenney 34
Patching Process: Non-Stores
JCPenney 35
Patching Process: Stores
JCPenney 36
13. Associated Forms
Sl No. Type of form Sample
1. Intake Form Intake

Form.doc.docx
2. Package Release Form

Package Release
Form v1.0 .doc
JCPenney 37

Jcpenney: Standard Operating Procedures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jcpenney: Standard Operating Procedures

Uploaded by

Copyright:

Available Formats

JCPenney

Standard Operating Procedures

A comprehensive guide on the Software Packaging and Deployment process

© Copyright and Trademarks

Copyright © 2019, J. C. Penney Services India Private Limited

JCPenney is a registered trademark of JCPenney. Other names may be trademarks of their

SOP_SPAD_v1.0 Biju. K SPAD Team D. N. Naveen Kumar Initial Release

1.1 Understanding SCCM

 Gathering Asset Intelligence

Team / Stakeholder Requirements Contact information

Infrastructure Escalations – L3 Bangalore:

Home office  For non- IO-ITFO-Alliance -IO-ITFO-Alliance-dl@jcp.com>;

Kingsuk  For stores Chakrabarty, Kingsuk - kchakra2@jcp.com

Table 1: Stores contact information

Team / Stakeholder Requirements Contact information

PDA Team For package- Bangalore:

MPU For package- Plano

3.2 Functional Requirements

 Server running System Center 2012 Configuration Manager

3.2.1.1 Supported Operating Systems

3.2.1.2 Unsupported Operating Systems

4. SCCM Monitored Infrastructure

Bangalore Endpoint 753

IBO Endpoints 436

US End Points 8762

Non-Store servers 1420

SQL Server 154

UCCE (other supported devices) 40

HYP Servers 1795

Store Registers 28603

Store Servers 1844

The general steps for repackaging an application are:

5.1 Requirement Gathering

The sample intake form is placed as an appendix here.

 Filled intake form

Input Filled Intake form

The following flowchart explains the process or steps involved in repackaging an

Repackaging may also include some scenarios like:

The repackaging process is performed using a third-party application called Flexera.

5.3.1.1 Package Unit Testing

Test Action Result

Install silently Msiexec /i <package> /qn No runtime errors

Uninstall silently Msiexec /x {ProductCode} No runtime errors

Install silently Msiexec /i … /qn No runtime errors

Self-Repair Break a KeyPath, launch No runtime errors

Launch all Initiate all shortcuts All shortcuts should launch

Directory table Check if the directory table is The product should be in

Test Action Result

Reboot check Perform a manual Reboot The machine starts up

File Extension Launch or print a document No runtime or event log

Database If possible, database connectivity No database connectivity

Common File If the application shares a The file extension should be

Lockdown Using a clean machine, install the No runtime or permission-

Uninstall It is not necessary to uninstall this “Clean” uninstall (No

NT Services are No runtime or event log

 The created package functions as per the request.

5.3.1.3 Pre-UAT Checks

1. Importing an application/package to SCCM.

5.4 User Acceptance Testing

6.3 Third-party Application

1. Search and download the relevant application update.

Sample Deployment Schedule

The flowchart for the store patching process is attached as an appendix.