A
new challenge to face! An X number of SharePoint 2010 standalone installations
must be installed within a specific configuration in short time. Let´s try
cloning a SharePoint standalone installation!
Our
scenario:
- Virtualization under Hyper-v system.
- A new virtual machine was created with
Windows 2008 R2 operating system.
- First of all we installed SQL 2008 R2 (default
instance), a clean SharePoint 2010 + SP1 + 2 language packs + extra software
(visual studio..)
- All security updated applied.
·
And the following SharePoint service
applications:
- Access Services
- Business Data Connectivity Service
- Excel Service
- Search service Application
- Secure Store Service
- State Service
- Visio Service
- Web Analytics Service
- Word automation Service
Let´s
call this machine the master server.
We
saved the master server as template and produced X of new virtual machines. New
IPs must be setup.
A recommend you to keep the master machine shutdown to avoid any confusion.
X
new virtual machines were created based on the template. And here our work
starts! We split the tasks into 2 phases and a validation part:
- Before changing server name
- After changing server name
- Validation of the new SharePoint servers
Note:
Along the procedure some restarts of
the server and the IIS will be necessary.
Use the farm account for running these
steps.
You will need:
- Farm account
and password
- Security
token application: pass phase in case you configured the key for access and visio
A.
Before
changing server name
- Adding a new entry for the Central
Administration AAM (alternate access mapping) with the new server name.
- Add entry for the
backconnectionhostname in the registry.
- Changing the name of the configuration
database name:
Run
powellshell:
"Stsadm -o renameserver
-newservername {YourNewServerName} -oldservername {YourOldServerName}"
>>>> server name change and
sysprep <<<<<
- (Start->Administrative
Tools->Server Manager. From the Server Summary section, select
"Change System Properties." Click the "Change" button
from the "Computer Name").
- Restart the virtual machine.
- Sysprep.
- Apply the new IP address.
B. After server name changed (sysprep)
- Access de virtual machine. Try opening
Central Administration console. If you receive a "503 service
unavailable" error change the
account for the application pool for localserver. Apply changes, recycle the
pool and change back for the farm/setup account. Now you should be able to
access. Detailed steps:
access
to IIS >> application pool: SharePoint Central administration v4> advanced settings>> process
model: identity: Select built-in account: local service. OK
Now
change the identity back to it´s original, which should be the setup farm
account (domain\account). You need the
password also.
Apply
the same procedure to the "SecurityTokenServiceApplicationPool" pool.
Now
you will be able to access to the Central Administration. Let´s continue with
the steps:
- Remove the old AAM entrance
(from the master server)
- Verify that the new configuration
database server appears in "servers in farm"
- Start the windows service: Claims to
windows Token Service. That´s due to the event id error:8306
- SQL configuration: Be sure you have changed both, the
server name and the IP. The second case is only affecting those scenarios where
we will need to access from outside of the server, but we should keep it clean
though.
SQL
server configuration manager > SQL server Network configuration: protocols:
TCP/IP: Ip addresses: IP address: Introduce the new IP. You must restart the
instance to apply the changes but we don´t need it immediately, you might wait
until next restart of the server.
- SQL alias: from cliconfg.exe apply the
SQL alias (be careful with the version 32-64bits, both are presented in 64bits
servers)
- Certificate of the Security Token
Service.
o
Export the certificates from the master server related to Sharepoint > STS
o
Import these 3 certificates into the
copied machines.
- Provision the general configuration for
the web applications. Open SharePoint 2010 management shell and run the
following commands:
$h = Get-SPServiceHostconfig
$h.Provision()
- Provision all the service applications:
$services = Get-SPServiceApplication
foreach ($service in $services) {
$service.provision();
write-host $service.name
- Reset the IIS: IIsreset /noforce
Table
with the tasks
Tasks
|
Notes
|
Tasks Before changing server name
|
Adding
a new entry for the Central Administration AAM
|
Central
Administration > AAM
|
Changing
the name of the configuration database name
|
Stsadm -o renameserver -newservername
{YourNewServerName} -oldservername {YourOldServerName}"
|
Add
entry for the backconnectionhostname in the registry
|
Registry:
Server
Server.domain
|
Server´s name change and sysprep
|
Tasks after changing server name
|
Access
to Central Administration
|
Error
503?
|
Remove the old AAM entrance
(from the master server)
|
Central
Administration > AAM
|
Verify that the new configuration
database server appears in "servers in farm"
|
Central
Administration
|
Start the windows service: Claims to
windows Token Service
|
windows
service
|
Adding SQL alias
|
Cliconfg.exe
|
Certificate of the Security Token
Service
|
Import
from the master machine
|
Provision the general configuration
for the web applications
|
$h = Get-SPServiceHostconfig
$h.Provision()
|
Provision all the service
applications
|
$services = Get-SPServiceApplication
foreach ($service in $services) {
$service.provision();
write-host $service.name
|
Reset
the IIS
|
IIsreset
/noforce
|
Validation of the new SharePoint
servers
|
Event log: application and system
|
Revision
|
Health analyzer
|
Revision
|
Service applications: revision every
single application to validate the access and the availability (start)
|
Revision
|
Creating a new web application and a
site collection and check the event log
|
Revision
|
A.
Validation
of the new SharePoint servers
Many
things must be taken into account when cloning a SharePoint server, too many
things to pass by hence the way to be sure is checking deeply the server
status. Some points to take care of are:
- Event log:
application and system
- Health analyzer
- Service applications: revision every
single application to validate the access and the availability (start)
- Creating a new web application and a
site collection and check the event log.
The
sumup of this experience is that the main issue found along the procedure was
related to the token service and security certificates. The token service is
created during the installation of the product and the only way of re-creation
is running the SP wizard of through power shell. We decided avoiding this step.
If you might found an easier or better way of procedure please share :-) we´d
be grateful.
