lunes, 29 de julio de 2013

Infopath error:The server is currently being taken down for maintenance::MOSS2007, SP2010

That was certainly not an expected incident, easy to resolve if you would point out where the issue was.

Infopath forms failed in an specific site, the rest of the site collections seemed to work fine.The message that the user got was:

The server is currently being taken down for maintenance. Check with your system administrator to see when this server is scheduled to come back online.

And the image (I will show both versions, MOSS 2007 and SP2010 version of the message):




It was after testing some backup application related to SharePoint.

The version was SharePoint 2010.

After reviewing the database status (read only = NO) and that the Site collection was not lock through the Central administration we checked the status of the farm, because the message was quiet explicit about the maintenance part, and the only idea taht pop-up in my head was that old-fashioned command related to Quiesce.

Open a Sharepoint Power shell using an account with priviledges over the SharePoint (sharepoint administrator) and run the following command:

stsadm.exe -o quiescefarmstatus
If the result is "Farm is Quiesced" then run the following command in order to change this status of the farm, which normally is used for maintenance purposes.

stsadm.exe -o unquiescefarm

stsadm.exe -o quiescefarmstatus
you should get now "Farm is not Quiescing"

jueves, 6 de junio de 2013

Clone a SharePoint standalone installation


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:

  1. Before changing server name
  2. After changing server name
  3. 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.

jueves, 28 de marzo de 2013

Recycle bin retention period: maximum days


I had the 70-668 PRO SHAREPOINT 2010 exam today and a doubt pop-up in my mind when reading a question.

It was related to how long a document could stay in the recycle bin. And I didn´t know the answer. When I tried to find some answer I couldn´t find it at Microsoft technet or at least I couldn´t place it, all what I found is:

·  You can specify a time after which items in the Recycle Bins are deleted, or you can specify that these items should never be deleted. By default, items are deleted after 30 days.
·  You can specify a percentage of live site quota for second-stage deleted items. The default setting is 50 percent. You can also turn off second-stage Recycle Bins. If you select Off, site collection administrators cannot recover items deleted from end-user Recycle Bins.The second-stage Recycle Bin quota percentage must be a value from 1 through 500.


So I tried to modified the default value (30) for a bigger one in "delete items in the Recycle Bin" After : 9999999999 and I got a message "Recycle bin retention period must be between 1 and 10000 days"

More than 27 years for retention.. nice number.

Moreover you might choose "never" also, which means that all deleted items will remain in the recycle bin until you will remove from there manually. This option may require extra management to avoid storage issues ...

viernes, 22 de marzo de 2013

Excel Services crashes when creating


I needed to create the excel Services, initially an easy and fast task to execute throught CA. But not so easy ended.

PROCEDURE
  1. Creating the service:
Application management > Manage service applications > New > excel Service application
  1. Starting the service on the app server you choose
Manage servers in this farm> server > excel calculation services: start
  1. Associating the web application with the service: That´s the point that in fact fails behind the scenes, on the SQL part.
Application management >> configure service application associations

ERRORS ..

In fact I got different errors in 2 farms. The ULS logs show:

Farm A: there was an error in communicating with excel Calculation Services  http:// …. Exception: the remote server returned an error: (403) Forbidded

 FARM B:There was an error in communicating with Excel Calculation Services http://AppServer:32843/ceaafed8560b789456b1c0b95625c889a/ExcelService*.asmx exception: The remote server returned an error: (403) Forbidden. [Session:  User: DOMAIN\poolaccount].
In the application Log you might find:

Unexpected error when trying to access service settings in the configuration database. Make sure the proxy for this service application is a member of the default proxy group for the active web application. Error = ExcelServerWebServiceApplication.Local: Could not get the web application associated with this context. This indicates that the Excel Server service is not properly registered or provisioned..
 
SOLUTION

After some research I found out that Microsoft already published the issue/workaround. It seems that when you create the service after the installation of the farm the privilege that the service account needs to access to the content database of the web application is missing. You need to do it by command line. The nice thing is that it´s working properly:


  •  $w.GrantAccessToProcessIdentity("domain\serviceaccount")

  •  $excel = Get-SPExcelServiceApplication

  •  $excel.Provision()

 

viernes, 15 de marzo de 2013

Security vulnerability :: SharePoint 2010 SP1_March, 12

MS13-024: Vulnerabilities in SharePoint could allow elevation of privilege: March 12, 2013


More info: http://technet.microsoft.com/en-us/security/bulletin/ms13-024#section6

SharePoint XSS Vulnerability - CVE-2013-0083
An elevation of privilege exists in Microsoft SharePoint Server. An attacker who successfully exploited this vulnerability could potentially issue SharePoint commands in the context of an administrative user on the site.

To view this vulnerability as a standard entry in the Common Vulnerabilities and Exposures list, see CVE-2013-0083.

Remove-SPContentdatabase VS deleting the BBDD using Central Administration interface

There´re some differences when handling sharepoint tasks using the Central Administration interface and the cmdlet. This fact is more obvious within time and issues. Here one of them ....


Which is the difference between deleting a content database from cmdlet and for Central Administration? … Yes, there is a difference, and it´s a big one!

  • Central Administration: in fact you dismount the database from the site, It will not appear related to any site but it is not being removed from the SQL server itself, you always have the option of attached it again

  • Cmdlet remove-spcontentdatabase. When you run this command (ie.  remove-spcontentdatabase Wss_Content_LibraryHome) 2 questions will pop up:

Are you sure you want to perform this action?
Removing "Wss_Content_LibraryHome" will permanately delete the SQL database, permananetly deleting all content stores within it.