How it works
·
After you install, Solution Deployer for SharePoint
2010 provides a config.xml file in
which there are various values to be populated as per your environment. This is
a onetime task and you can populate
multiple environments too. More details about this xml and how to fill it
following sections.
·
Copy the WSP files to a location on any of the
servers or all the servers along with the required text files.
·
Run the tool by selecting the required options
in the GUI. Check the status of the deployment in the status update pane.
That’s it!!
Prerequisites
• SharePoint
farm should be reachable from the computer the tool is running.
• PowerShell
Remoting should be enabled on both the SharePoint servers and the computer on
which the tool is running.
• The
tool is supported to run on Windows 7, Windows Server 2008 and Windows Server
2008 R2. (CredSSP authentication support)
• Make
sure the text files for each set of WSPs/change is available as described in user
guide section.
Installation (One Time)
Installation is pretty much easy. Download the zip
file to any server or computer from which you can reach the farm by executing
the tool. Here is the step by step process in detail.
• Extract
the contents of the zip file and leave the directory structure intact.
• Open
PowerShell console with administrative privileges and execute the script ‘SPDeployerPreRequisiteSetupClient-OneTimeRun.ps1’
under “FirstTimeSetup-OneTimeExecution”
folder. Remember that this should be run on the computers on which this tool is
running.
Type Yes or Run Once where ever
the script prompts you to do so.
• Copy
the file “SPDeployer-PreRequisiteSetupServer-OneTimeRun.ps1”
to all the application and web front end servers of the farm to a directory.
• Log
on to all the application and web front end servers of the SharePoint farm and
open
PowerShell console with
administrative privileges. Change the directory to the place where
you copied the script to “SPDeployer-PreRequisiteSetupServer-OneTimeRun.ps1”
and execute the same. Type Yes or Run Once where ever the script prompts you to
do so.
That’s it. The environment is ready to run the tool.
Configuration – Modifying
Config.xml (One Time, and later, Need based)
This section basically describes about setting up
config.xml. This xml contains all the SP2010 farm related information required
for successful functioning of the tool. This is an Easy to fill xml. Caution
should be taken not to change any tags. Only the values should be changed
according to your needs. The points below explain about various tags. The tags
missing in these point are obvious and need not be explained.
The XML is structured this way.
Parent Node
(SHAREPOINT_CONFIGURATION) -> Environment Classification ->Application
Classification in each environment
1) Fill
the “EnvName” value as your environment name. For example, Development,
Disaster Recovery etc.
2) Fill
the value between tags as the enterprise domain where the
sharepoint farm resides and does user authentication.
3) Fill
the value between tags as the username with farm
admin privileges or privilege to deploy WSPs and manage features. Do not
mention
‘domain\username’ format but just
‘username’
4) Fill
the value between tags as the encrypted password of
the farm admin user mentioned above. The password can be encrypted using
“encryptString.ps1” PowerShell script present in
“EncryptionTool” directory of the extracted and installed folder. Right click
on encryptString.ps1 and select “Run with PowerShell”. Provide the plain text
password at the prompt and hit Enter. You will get the encrypted string. Copy
and paste the encrypted string in between these tags in the xml.
5) Fill
the value between tags with all the application and web
front end server names in comma separated format. The first server mentioned in
the csv server list is the server used by the tool to do all the deployment
work.
6) Fill
the value between tags with UNC or absolute path where you
want to store all the logs of this tool. This logs who is working on the
deployment and all the text shown in the status update pane.
7) Fill
the value between tags with the central administration solution
management page URL.
8) Fill
the value of “AppName” in tags with the web application name.
9) Fill
the value of tags with the absolute path on
the server where you store all the WSPs and the related text files. More details
about the text files in the User guide.
10) Fill
the value of with the URL of the web application as you see in
central administration.
11) Fill
the value of tags with the relative path of the IIS
virtual directory of the web application.
The tags can be of any number
based on your setup and so the applications under tags.
Quick User Guide
The following are the quick steps to
jump start using the tool.
1) Maintain a common folder (deployment
scripts base path) on any server of sharepoint farm and copy the WSPs deployed
to that folder
2) Create and copy 2 text files into the
same directory whose names are of format “ChangeNumber_WSPList.txt” and
“ChangeNumber_Features.txt” where change number is the actual change number for
this release.
3) List the wsps to be deployed in
ChangeNumber_WSPList.txt comma separated with URL to which the WSP should be
scoped. If it is global do not mention anything.
4) List the feature IDs associated with
the WSPs to be activated and deactivated in the ChangeNumber_Features.txt file.
5) Run the SharepointDeployerV3.1.exe
and fill in the required details. Click Apply Config button.
6) This populates the WSP text files to
be used for the deployment and features for activation and deactivation. Select
the right options for the deployment and click Deploy.
7) Check the status pane for updates.
User Guide
In order to maintain consistency, especially when
deploying same set of WSPs across various environments, the following process
works well but you can modify it as you need. The following steps are explained
considering a general scenario of every enterprise into consideration. It might
differ a little from what you do but it can always be customised.
Consider there is a requirement from business to
sharepoint developers and the developers have written code in the form of 3
WSPs which creates 2 features to a sitecollection of web application webapp1.
However all the WSPs are existing WSPs in production and they have to be
replaced with these new ones. They want to deploy these 3 WSPs in Dev
environment first. The enterprise is using Solution Deployer for Sharepoint to
do the WSP deployments. Considering the enterprise practises ITIL Change and Release
management, this is what the developer does.
1) The
developer creates a Change record and the change number is RFC12345. This is
used to track the deployment till it reaches production from development.
2) While
building WSPs, the developer also creates two text files with following name
format. This is a must.
a.
RFC12345_WSPList.txt
b. RFC12345_Features.txt
The WSPList text file is used while retraction and
deployment and Features.txt file is used during feature activation and
deactivation. You can skip creating any of these files if you are not doing
retraction/deploying or activation/deactivation.
Basically it will contain the list of WSPs along
with any specific URL to which the WSP need to be deployed to. The URL and the
WSP are separated by a comma. Also if the WSP has to be deployed globally,
there is no need to place a comma.
4) The
content of RFC12345_Features.txt is as follows.
5) Now,
the directory in which you copied the WSPs and the above text files is the
deployment scripts base path and the absolute path of this directory should be
placed in the tags in config.xml file.
7) Provide
the RFC Number in the first field. For example RFC12345
9) Select
the application of the environment to which deployment is happening
10) Click
on Apply Config to populate all the fields in section below. The fields will be
auto populated based on the process that we have followed earlier. In cast the
file names or paths are different, you have an option to change them.
11) Check the boxes for the actions that you want to carry out and click on Deploy button.
12) The
tool will complete all the required validations during execution and complete
the required actions that are selected. The status is shown in the status
field.
Points to Note:
a) The
tool is basically a powershell script wrapped up in an exe. So there will be a
console window that opens along with the tool. The console window displays any
errors during execution and also displays overall status messages as well.
If you do not want the console to open and you want
just the GUI, execute the exe with – noconsole option.
b) Make
sure you populate the encrypted password and other values in config file
properly. Any mistakes in config file will lead to mistakes and errors. The
encrypted password feature is to enhance the security.
c) If
you do not want to follow the process mentioned above, you could still use the
tool by modifying the text file paths on the server during execution.
d) In
case you want to use different text files for retraction and deployment, you
have an option in the tool to retract using a different file. By selecting the
option, the tool will consider the file that you mention here for retraction
and the actual WSPList file for deploying WSP files.
e) There
is an option for config file changes which halts the execution of the tool in
case you want to make any other changes after
deactivation/retraction/deployment/activation steps. This might include
changing any web.config entries or owstimer.exe.config entries etc. You can
select the options on prompt to continue further with IIS reset and timer
restart.
f)
The sequence of actions carried out by the tool
is
a.
Deactivate features
b. Retract
Solutions
c.
Deploy solutions
d. Activate
features
e. Config
File Changes
f.
IIS reset
g.
Timer restart
If you do not select any option in the above list,
the tool will skip that action but the sequence is maintained.
No comments:
Post a Comment