SharePoint 2010 Application Pool

There might be a situation where you want to alter the identity for the IIS application pool under which your SharePoint 2010 web applications are running.

You might be tempted to navigate to the IIS settings and alter the identity in there:

This is not recommended.
It’s best practice to run application pools under a domain user account, i.e. SP_ServiceApps. This account is best managed using Managed Accounts.
To change the identity for an application pool, log into Central Administration and follow these steps:

1. Go to Security and under General Security, click Configure Service Accounts.
2. Select the application pool from the components drop-down listbox (1)
3. Select the managed account (2) that you want to use as
   the identity for this application pool, or register a new managed
   account in SharePoint 2010, using the Register a new managed account link.
4. Click the OK button.
5. You’ll be warned that this action requires an IIS reset on all servers, click OK.
6. Perform a iisreset /noforce on all WFE servers in the farm.

Modelo de Migración usado: “side-by-side” SQL SERVER

Se trata del modelo de migración más común y más versátil puesto que el destino final es una nueva instancia de SQL Server 2012, bien sea en la misma máquina donde reside la antigua, o un nuevo servidor preparado especialmente para la migración.

Las ventajas frente al modelo de actualización “in-place” son:

ü      Se pueden migrar componentes de forma atómica. Esto quiere decir, que podemos migrar únicamente el motor relacional, dejando que el resto de servicios permanezcan funcionando en la antigua instancia de SQL Server

ü      Se permite la migración de 32 a 64 bits

ü      Se permite la actualización de la versión del Sistema Operativo (normalmente viene asociado a un nuevo servidor en el que se instala la última versión de Windows Server pasando por ejemplo de un Windows Server 2003 con SQL Server 2005 a Windows Server 2008 R2 con SQL Server 2008/2008 R2/2012)

ü      Se permite la migración a un servidor más potente. Al no estar ligados a la actualización del servicio, se puede comprar nuevo hardware destinado para SQL Server, y migrar los datos de la antigua instancia al nuevo servidor.

ü      Se puede migrar un conjunto de bases de datos, en lugar de todas las bases de datos: escenario apropiado en instancias de SQL Server que tienen aplicaciones de diferentes proveedores y alguno de ellos no soporta “todavía” la migración a SQL Server 2005-2008-2008R2-2012.

Pasos para una migración: “side-by-side”

1. Instalar una nueva instancia SQL Server 2012.

2. Ejecutar el programa Microsoft SQL Server 2012 Upgrade Advisor

contra la instancia (SQL Server 2005, 2008, 2008 R2) a migrar y resolver

todas las advertencias.

3. Parar toda actividad de la instancia SQL Server a migrar (desconexión de

usuarios incluida).

4. Transferir los datos a la nueva instancia (mover backups, paquetes DTS,

etc.)

5. Restaurar los objetos sobre la nueva instancia.

6. Una vez validado que todo funciona con normalidad, desconectar o

desinstalar la instancia de SQL Server migrada si es necesario.

Microsoft SQL Server 2012 Upgrade Advisor

La herramienta se encuentra incluida en el DVD de instalación, sin embargo

se puede descargar de la siguiente dirección:

http://www.microsoft.com/downloads/details.aspx?familyid=F5A6C5E9-

4CD9-4E42-A21C-7291E7F0F852&displaylang=en

SQL Server Upgrade Advisor (SSUA) está pensado para instalarse en un equipo diferente al de producción, por lo que está preparado para solicitar la instancia y servicios a analizar, así como el usuario (con permisos sysadmin) que necesitemos para conectarnos y realizar el análisis.

Tareas de la migración: “side-by-side”

1. Ejecución del SQL Upgrade Advisor.

2. Interpretación y explicación del resultado del SQL Upgrade Advisor.

3. Instalación de SQL Server 2012 siguiendo buenas prácticas.

4. Plantear migración de paquetes DTS a SSIS o ejecución en modo compatibilidad.

5. Plantear migración de Cubos SQL 2005, 2008 y 2008 R2 regenerándolos desde 0, actualizándolos automáticamente con el asistente o simplemente manteniendo la instancia de SQL 2005, 2008, 2008 R2 pero accediendo desde SQL 2012.

6. Creación de un script de migración para el día de paso a producción y realizar las pruebas correspondientes en pre-producción.

Planificando la migración, Plan de pruebas y validación SQL Server

Planificando la migración        

Antes de iniciar a planificar la migración debemos de validar los cambios de

arquitectura y mejoras de la herramienta. Con este paso podemos detectar

posibles pérdidas de funcionalidad con las que actualmente estamos

trabajando.

Compatibilidad con versiones anteriores

http://msdn.microsoft.com/es-es/library/cc280407.aspx

Características obsoletas de SQL Server en SQL Server 2014

http://msdn.microsoft.com/es-es/library/cc707789.aspx

Compatibilidad con versiones anteriores del Motor de base de datos de SQL Server

http://msdn.microsoft.com/es-es/library/ms143532.aspx

Principales cambios en las características del Motor de base de datos de SQL Server 2014

http://msdn.microsoft.com/es-es/library/ms143179.aspx

Características descontinuadas de SQL Server en SQL Server 2014

http://msdn.microsoft.com/es-es/library/cc707782.aspx

Plan de pruebas y validación

El mejor escenario para cualquier migración es aquella donde se puedan realizar pruebas, ya que ahí será donde validemos si todo se puede realizar correctamente, y en el caso de que no, poder ver los potenciales errores para poder proporcionar una solución.

Bajo este escenario los pasos a seguir son:

• Revisar los problemas de migración

• Corregirlos (a nivel de código)

• Aplicarlos

• Ejecutar nuevamente Microsoft SQL Server 2014 Upgrade Advisor (SSUA)

y corroborar que ya no exista error alguno.                  

Llevándo bases de datos a SQL Server 2012

Una vez resueltos los problemas de migración en código. Ahora nosotros debemos de llevarnos la base de datos a la nueva versión los pasos a seguir son:

1. Restaurar la base de datos en el servidor SQL Server 2012

2. Cambiar compatibilidad de 2005, 2008, 2008 R2 a 2012

--Primero ponemos la base de datos a modo mono-usuario

ALTER DATABASE [BDMigrar] SET SINGLE_USER

GO

--Cambiamos el nivel de compatibilidad de 2005/08/08R2 a 2012

EXEC sp_dbcmptlevel [BDMigrar], 110;

GO

--Por ultimo regresamos la base de datos a modo multi-usuario

ALTER DATABASE [BDMigrar] SET MULTI_USER

GO

3. Ejecutar DBCC CHECKDB para validar la salud de nuestra BD

USE [BDMigrar]

GO

DBCC CHECKDB;

GO

4. Ejecutar DBCC UPDATEUSAGE para actualizar paginas

USE [BDMigrar]

GO

DBCC UPDATEUSAGE ([BDMigrar])

GO

5. Reconstruir índices

USE [BDMigrar]

GO

ALTER INDEX [NombreIndice] ON [dbo].[TablaMigrada] REBUILD

PARTITION = ALL WITH ( PAD_INDEX = OFF,

STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON,

ALLOW_PAGE_LOCKS = ON, ONLINE = OFF, SORT_IN_TEMPDB = OFF

)

GO

6. Actualizar Estadísticas

use [BDMigrar]

GO

UPDATE STATISTICS [dbo].[TablaMigrada]

WITH FULLSCAN

GO

The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started. Please Contact your Administrator.

The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started. Please Contact your Administrator.

This error shows up on the Term Store Management page, located in Central Administration and a site's Site Settings page. When I get this error it's usually when building a new farm and its cause is one of a handful of simple things, each with it's own simple fix. Guru Pratap from Microsoft has a great blog post about this error with the common resolutions: SharePoint Error : The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started.
Today I was looking at a couple of new development VMs that had the issue where it was working in Central Administration but not in Site Settings. None of the usual fixes worked. In fact, all of the settings had been correctly applied before I even looked at the server.

I checked the ULS logs and found an exception suggesting invalid access while trying to write to a registry key:

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Failed to get term store during cache check for changes.  Proxy 'Managed Metadata Service'. Exception: System.Security.SecurityException: Requested registry access is not allowed.      at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication.GetMOSSInstallPath()      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.GetChannel(Uri address, Boolean& cachedChannel)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.<>c__DisplayClass2f.<RunOnChannel>b__2d()      at Microsoft.Office.Server.Security.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.RunOnChannel(CodeToRun codeToRun, Double operationTimeoutFactor)      at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyProxyAccess.GetChangeTime(Guid rawPartitionId, Nullable`1 groupGuid, Nullable`1 termSetGuid)      at Microsoft.SharePoint.Taxonomy.Internal.DataAccessManager.GetChangeTime(Nullable`1 groupGuid, Nullable`1 termSetGuid)  at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyCache.CheckForChanges(Boolean enforceUpdate) The Zone of the assembly that failed was:  MyComputer Failed to get term store for proxy 'Managed Metadata Service'. Exception: System.Security.SecurityException: Requested registry access is not allowed.      at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication.GetMOSSInstallPath()      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.GetChannel(Uri address, Boolean& cachedChannel)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.<>c__DisplayClass2f.<RunOnChannel>b__2d()      at Microsoft.Office.Server.Security.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)      at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.RunOnChannel(CodeToRun codeToRun, Double operationTimeoutFactor)      at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyProxyAccess.GetChangeTime(Guid rawPartitionId, Nullable`1 groupGuid, Nullable`1 termSetGuid)      at Microsoft.SharePoint.Taxonomy.Internal.DataAccessManager.GetChangeTime(Nullable`1 groupGuid, Nullable`1 termSetGuid)      at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyCache.CheckForChanges(Boolean enforceUpdate)      at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyCache.GetCache(TermStore termStore, Boolean updateCache)      at Microsoft.SharePoint.Taxonomy.TermStore.get_Cache()      at Microsoft.SharePoint.Taxonomy.Internal.SharedItemManager.GetTermStore(Boolean addOfflineWhileFetching, Boolean& partitionCreated)      at Microsoft.SharePoint.Taxonomy.TermStore.Initialize(MetadataWebServiceApplicationProxy proxy, Guid partitionIdRaw)      at Microsoft.SharePoint.Taxonomy.TermStore..ctor(MetadataWebServiceApplicationProxy applicationProxy, TaxonomySession session, Guid rawPartitionId, Boolean updateCache)      at Microsoft.SharePoint.Taxonomy.TaxonomySession.Initialize(TaxonomySessionContext sessionContext, Boolean updateCache, SPWeb webForPermissions, SPList listForPermissions, Boolean includeOfflineTermStores)  The Zone of the assembly that failed was:  MyComputer

Searching for the exception I found a TechNet forum post that outlined what I had planned to do next: check which registry key was trying to be accessed and grant the permissions: Managed Metadata Service not working

Before I started changing permissions, I looked at the WSS_ADMIN_WPG local machine group to make sure that it existed and it contained the web application pool service account. The WSS_ADMIN_WPG group provides write access for SharePoint service accounts to local resources like files and registry keys on the local server.


In this case, the service account was in the group which means the Term Store Management page should be working. Knowing this, all we need to do is fix the permissions. Microsoft has documented the permissions on TechNet in Account permissions and security settings. Rather than doing this by hand, or running the risk that some of the other permissions were not correctly set, you can run the Initialize-SPResourceSecurty cmdlet  in an elevated SharePoint Management Shell. This will reset all file system and registry permissions.

?

1	Initialize-SPResourceSecurity

After running, reloading the Term Store Management page displays the page as expected:

Important: PSCONFIG is mandatory for July 2015 CU for SharePoint 2013

iisreset
psconfig.exe -cmd upgrade -inplace b2b

Resolution to UpgradeTaskFailConfigSyncDisplayLabel in December CU SharePoint 2010

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

SharePoint Error : The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started.

http://blogs.msdn.com/b/guruketepalli/archive/2013/08/09/sharepoint-error-the-managed-metadata-service-or-connection-is-currently-not-available-the-application-pool-or-managed-metadata-web-service-may-not-have-been-started-please-contact-your-administrator.aspx

Search Administrative status = Paused for:External request

Luego de aplicar el CU de Agosto 2015 sobre una granja con SharePoint Server 2013, me reportaron problemas de conectividad con el servicio de Metadatos y Search.

Verificando el servicio desde la Central Administration el servicio de Search reportaba el siguiente estado:

Search Administrative status = Paused for:External request

Para resolver este estado ejecute el siguiente script desde SharePoint Managment Shell

• Add-PSSnapin Microsoft.SharePoint.PowerShell
  
  $ssa = Get-SPEnterpriseSearchServiceApplication –Identity "Search Service Application"
  
  $ssa | Resume-SPEnterpriseSearchServiceApplication

SharePoint 2013: August 2015 Cumulative Update Package Fails to Install

http://blogs.msdn.com/b/tehnoonr/archive/2015/08/28/sharepoint-2013-august-2015-cumulative-update-package-fails-to-install.aspx

Reorganizar y volver a generar índices

https://technet.microsoft.com/es-es/library/ms189858.aspx

Example: Index fragmentation with insert/updates, measuring it and fixing it

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/01/example-data-fragmentation-with-insert-updates-measuring-it-and-fixing-it.aspx