A very nice set of articles from Manuel Puron, System Center Premier Field Engineer (PFE) from Mexico City, have been released.
If you are visiting us from Latin America you might be doing this kind of searchs:
Well here you have the links to the different articlespart f this series
For more information around System Center Virtual Machine Manager please visit Manuel’s Blog at http://blogs.technet.com/manuelpuron
Duración: 50 min.
Tema: SQL Server 2014 para ITPros.
Descripción del tema: En esta tema hablaremos de las nuevas ventajas que nos ofrece SQL Server 2014.
Objetivo: Dar a conocer cómo funcionan las nuevas característica de SQL Server 2014 en el área de ITPro, lo que permitirá usar estas características para mejorar la disponibilidad de sus aplicación, tener un plan de recuperación rápido y efectivo y hacer decisiones informadas de porque ir a esta nueva versión de SQL Server.
Presentador: Edinson Medina
Idioma: Español
Tema: SQL Server 2014 para Desarrolladores.
Objetivo: Dar a conocer cómo funcionan las nuevas característica de SQL Server 2014 lo que permitirá usar estas características para mejorar el rendimiento de sus consultas y hacer decisiones informadas de porque ir a esta nueva versión de SQL Server..
A couple of weeks ago, a customer asked me how to setup BI capabilities in SharePoint and what were the different options they have available.
Is really cool to start seeing customers moving forward with SharePoint capabilities, from basic sharing and collaboration, to more complex scenarios like Business Intelligence.
For a complete guide around the different opptions and resources on how to enable BI features with SQL Server 2012 on SharePoint 2013 I invite you to read my new blog post here.
Happy SharePointing!
El mundo de los negocios es cada vez más demandante y requiere de profesionales con conocimientos sólidos sobre las tecnologías actuales y muy informados sobre las que están surgiendo.
Microsoft te invita este 17 de junio al "Microsoft Technical Day" en donde podrás seleccionar de entre 32 conferencias técnicas las que mayor interés tengan para ti o mayor impacto en el desarrollo de tu trabajo profesional.
Asiste el martes 17 de junio y convive con los 32 especialistas de Microsoft de diversas tecnologías, al tiempo que compartes, con 200 profesionales exitosos como tú, sus experiencias.
I remember the old days, when I wasn’t a fan of Installing SQL Server on Virtual Machines, but in todays world thanks to Hyper-V 2012 (and I guess VMWARE too), a lot of the resource bottlenecks for virtual machines has disappear. However still it’s not for every workload.
Recently I was on one of my clients that has a kind of big Virtual Shop on Hyper-V 2012R2, and he ask me. Well I’m planning the Installation of Multiple SQL Server for some management applications on a few VMs, how should I provide the High Availability for this?
That was a good question, we had many options, but we rapidly decided to have some kind of a Cluster, now we had two options, Clustering the Hyper-V Virtual Machines or doing a SQL Guest Failover Cluster between Virtual Machines.
The first one is a good option to mitigate downtime when the hardware failed, if one of the Hyper-V Virtual Machines Node failed, the Virtual Machines will just failover to another node, but what would happen just when the SQL Services failed? It wouldn’t trigger a failover, at least not by default, I guess we could create some kind of script to monitor the SQL Services and then trigger a VM Failover, but It doesn’t sound right. Now in the other hand we have Live Migration on this configuration, that allows us to move virtual machines with 0 downtime.
The second one is a great option, and have all the usual benefits of a SQL Server Failover Cluster, just use the 2 Virtual Machines, and create a SQL Cluster between this 2, this is called a SQL Guest Failover Cluster.
One of the question was could I combine the 2 options, and yes you could, but take into consideration the following:
Why? Lets suppose this scenario, We have 2 physical nodes were we create a Windows Cluster, and we configure 2 VMs as resources on this Windows Cluster (The First Option), you configure one VM to run in node1 and the other VM to run in node2, now you create a SQL Guest Failover Cluster between the to VMs (The Second Option). What will happen when Node1 crash (ex: Mother Board Failure), the 2 VMs will be running on Node2 consuming a lot of resources, and you will also not have real High Availability as your workload is running only in one physical server.
In conclusion, should I combine the two options, depend on you resource availability, and also how critical is the workload you are running against SQL. However what you should ALWAYS do is follow the best practices for configuring SQL on a Hyper-V environment.
Running SQL Server 2008 in Hyper-V Environment
Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations
Consolidating Databases Using Virtualization Planning Guide
Hope you like the post, you can follow me on twitter @SQLDixitox and on facebook https://www.facebook.com/SQLbyEdinsonMedina
Recuerdo los viejos días cuando no era un fanático de colocar a SQL Server en Máquinas Virtuales, pero hoy en día gracias a Hyper-V 2012 (y VMWARE), muchos de los cuellos de botella en recursos que existían en las máquinas virtuales han desparecido. Sin embargo aunque ha mejorado en gran medida no es para todas las cargas de trabajo.
Recientemente estaba en uno de mis clientes que tiene un Virtual Shop en Hyper-V 2012, y me pregunto: Estoy planificando la instalación de múltiples Instancias de SQL Server para algunas aplicaciones de administración en máquinas virtuales, como debo proveer la Alta Disponibilidad?
Esto es una Buena pregunta, tenemos varias opciones, pero rápidamente decidimos usar alguna forma de Cluster, entonces tenemos solo 2 opciones, Clusterizar la Máquinas Virtuales de Hyper-V o hacer un Guest Failover Cluster de SQL Server entre las máquinas virtuales.
La primera opciones es Buena para mitigar el downtime cuando el hardware falla, si uno de los Nodos de las Máquinas Virtuales de Hyper-V, las máquinas virtuales simplemente harán un failover a otro nodo, pero que pasaría cuando solo falle el servicio de SQL? Esto no iniciaría un failover, por lo menos no por defecto, supongo que se puede crear algún tipo de script que monitorea el servicio de SQL y luego disparar una falla a nivel de la VM, pero no suena muy adecuado. . Ahora por el otro lado, en esta configuracion tenemos Live Migration que nos permite mover maquinas virtuales con 0 downtime.
La segunda opción, es una excelente, y tiene todos los beneficios de SQL Server Failover Cluster, simplemente se usan las 2 máquinas virtuales, y se crea un SQL Cluster entre las mismas, esto es llamado un SQL Guest Failover Cluster.
Una de las preguntas fue, puedo combinar las 2 opciones? y Si se podría, pero tengan en consideración lo siguiente:
Porque? Supongamos un escenario, Tenemos 2 nodos físicos donde creamos un Windows Cluster, y luego configuramos 2 Máquinas Virtuales como recursos del Windows Cluster (La primera opción), se configure que una de las máquinas virtuales se ejecute sobre el nodo1 y la otra máquina virtual se ejecute en la nodo2, ahora se crea un SQL Guest Failover Cluster entre las máquinas virtuales (La segunda opción). Que pasaría cuando el nodo1 falle (ejm: Falla de la tarjeta madre), las 2 máquinas virtuales se ejecutaran en el nodo2 consumiendo una gran cantidad de recursos, y adicionalmente no tendrán verdadera alta disponibilidad ya que tu carga de trabajo esta ejecutándose en un único servidor físico.
En conclusión, debería combinar las opciones?, depende en la disponibilidad de recursos que tengas, también que tan crítica es la carga de trabajo que ejecutas contra SQL Server. Sin embargo, lo que SIEMPRE debes hacer es usar las mejores prácticas de configuración para SQL Server en un ambiente Hyper-V.
Espero que les haya gustado el contenido, me pueden seguir en twitter @SQLDixitox y en facebook https://www.facebook.com/SQLbyEdinsonMedina
Duración: 30 min.
Tema: SQL Server Sysprep.
Descripción del tema: En este tea tocaremos los pasos que debemos seguir para crear una imagen de SQL Server y Windows Server.
Objetivo: Dar a conocer cómo funcionan la caracteristica de sysprep en SQL Server y como la podemos usar para automatizar a creacion de maquinas con una Instancia de SQL Server.
Idioma: Ingles
En Junio y Octubre 2013 estuve apoyando a dos clientes en la actualización de sus plataformas productivas de Project Server 2010. Dado que en ambos casos no se disponía de procesos formales para actualizar de SharePoint 2010 o Project Server 2010, las actualizaciones se aplicaron en Producción:
El error: la página “Centro de Proyectos” no cargaba, se mantenía en el mensaje “Cargando”.
La revisión arrojó que la actualización no reconocía la zona horaria “-04:30 GMT” (Venezuela) que utilizaba la colección de sitios “PWA”.
La solución: luego de aplicar el Service Pack 2 en un ambiente de pruebas, la página “Centro de Proyecto” volvió a mostrarse satisfactoriamente, al establecer la zona horaria “-04:30 GMT”.
El error: la página “Centro de Proyectos” tampoco se mostraba, como ocurrió en el ambiente del cliente 1.
La revisión arrojó que la actualización a Service Pack 2 no reconoce la zona horaria “-04:30 GMT”.
La solución no he encontrado hasta este momento una actualización acumulada que solvente este error. Tan pronto conozca de la actualización que lo corrija, estaré refrescando esta publicación.
Mientras tanto, es importante recordar que Microsoft publica actualizaciones (parches) para todos sus productos, con el objeto de mejorar su funcionalidad en el transcurso del ciclo de vida de cada versión de los mismos. Microsoft publica cada actualización periódicamente (como un Service Pack o Actualización Acumulada) o de acuerdo a los errores descubiertos en el tiempo (como hotfixes). Para los productos y tecnologías SharePoint 2010, se debe considerar la actualización de todos sus componentes internos (Sistema Operativo, Base de Datos, Pre requisitos de SharePoint a nivel fundacional, Servidor y paquetes de lenguaje) y complementarios (Project Server, SQL Server Reporting Services en modo integrado con SharePoint, FAST entre otros).
Al aplicar actualizaciones a SharePoint 2010, considere:
Definir, implementar y mantener actualizada la estrategia de actualización, de acuerdo a las políticas de TI, Seguridad, continuidad de negocios de su organización.
Mantener las tecnologías y Productos SharePoint 2010 actualizados al menos con el Service Pack más reciente.
Aplicar actualizaciones acumuladas (CU por sus siglas en Inglés) solo cuando su Plataforma presente algún problema que sea solventado por el CU.
Revisar las secciones “Resumen” y “Resolución” de los artículos que describen los CU’s que usted prevé aplicar:
Resumen: describe la actualización y en algunos casos, los problemas que se pueden presentar luego de aplicar la actualización, así como pueden ser solventados.
Resolución: resume los problemas que se corrigen, los pre requisitos para la instalación, reinicio y archivo de información.
Artículos recomendados:
Software updates overview (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ff806329(v=office.14).aspx
Updates for SharePoint 2010 Products (http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx )
Deploy Project Server 2010 updates (http://technet.microsoft.com/en-us/library/gg598486(v=office.14).aspx )
During June and October 2013, I was supporting two customers in Venezuela, in order to update their SharePoint 2010 and Project Server 2010 production environments. Customers did not have testing environments, neither a formal patch management strategy, therefore, they decided update directly in Production:
The error: “Project Center” page, of PWA site only show the message “loading” and did not display the Project center info.
The troubleshooting raised that these updates does not consider time zones with a half hour, like “-04:30 GMT” Venezuela’s time zone.
The workaround was change the time zone of the PWA’s site collection. Customer needs to consider the impact of this change for its contents, workflows and any customization that use the time zone. Microsoft Support has delivered a private Hot Fix for the environment of this customer.
The solution was found by applying SharePoint Server 2010 and Project Server Service Pack 2 in a QA environment, the “Project Center” page was rendered successfully, using the “-04:30 GMT” Venezuela’s time zone.
The error: It was the same like Cutomer 1: “Project Center” page, of PWA site only show the message “loading” and did not display the Project center info.
The troubleshooting raised a similiar situation like Cutomer 1. The Service Pack 2 (Spanish) does not consider time zones with a half hour, like “-04:30 GMT” Venezuela’s time zone.
The workaround set the "PWA" site collection's time zone to a value different to “-04:30 GMT” (or any time zone with 30 minutes).
The solution I don't found a solution at this momento. I will be updating this post as soon I find a Cumulative Update that fixes this issue.
Meanwhile, it’s important remind that all Microsoft platforms are subject of updates (patches) in order to correct / improve its functionality, during the life cycle of their inner versions. Such updates are published periodically (like Service Packs or Cumulative Updates) or according to issues discovered at any time (like hot fixes). For SharePoint Server 2010 products and technologies, the update must consider all inner components (Operating System, SQL, SharePoint Prerequisites, Foundation, Server, and Language Packs) and dependent components (Project Server, SQL Server Reporting Services integrated mode, FAST and so on).
When applying updates for SharePoint 2010 Products and Technologies, it’s important to consider:
Define, implement and keep an updated documentation of the patch management strategy, according to your IT, Security, Business Continuity policies.
Microsoft recommends:
Keep SharePoint 2010 Products and Technologies updated with the last Service Pack released.
Apply Cumulative Updates (CU’s) only when your platform have issues that are fixed with a CU.
Summary: In this section, you can find a short description about the update, and in some cases, describe known issues that must be addressed after apply the update.
Resolution: This section summarize the issues fixed in this CU, the prerequisites to install, restart requirement and file information.
Recommended reading:
Originally posted at http://blogs.technet.com/b/mspfe/archive/2013/12/11/tips-and-tricks-from-the-field-on-the-new-distributed-cache-service-in-sharepoint-2013.aspx
Author: Vladimir Medina , SharePoint PFE, LATAM
If you, like me, are playing with SharePoint 2013 or if you have plans to migrate/deploy SharePoint 2013, you may have already heard about Distributed Cache (a.k.a. Velocity or AppFabric). In this post, I’d like to make you aware of some tips from the field that may help you avoid some serious issues in your production Farm.
First things first, see the following articles to learn about planning and managing Distributed Cache on SharePoint 2013:
Plan for feeds and the Distributed Cache service in SharePoint Server 2013
Manage the Distributed Cache service in SharePoint Server 2013
As you know, real world scenarios are always different and more challenging than TechNet “ideal world” and some tips that we noted from Premier support cases are really valuable:
If you’d like to sleep well before and after your new SharePoint 2013 deployment/migration process, I encourage you to bookmark this article . I’m also really interested in your experience and comments, so please share your stories with us and help us learn and share more tips about SharePoint – all will be welcomed!
En esta sesión hablaremos de la nueva caracteristica de SQL Server 2012, AlwaysON Availability Group y como usarlo en un ambientes de Alta Disponibilidad y Recuperacion de Desastres.
Format: wmvDuration:
Some weeks ago I was asked to help with a performance issue with some MDX Queries.
I was shown what the customer wanted to achieve, they needed to calculate some metrics including sampling errors using the method of “Conglomerados Últimos” (This can be translated to “Conglomerates Last” Method), this method was created by a Spanish Researcher and publish in a Spain Publication to calculate sampling errors a posteriori when the sample is stratified. This method is described in Spanish (Sorry I don’t an English version of this document) here http://dialnet.unirioja.es/descarga/articulo/250808.pdf
Just trying to understand the method and formulas was hard, but the customer had already an elegant solution using an MDX Script and the SCOPE statement. So I focused on the performance issue instead of trying to understand the formulas.
After a couple of hours I found out that the formula was using cell by cell calculation instead of block calculation, then found the operator in fault (the “^” operator) and after a small change (multiply the measure by itself) the query improved from around 30 seconds to 1 second.
You can find some details about the operators that support block computation in “Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services” found in http://www.microsoft.com/en-us/download/details.aspx?id=661, you can also find some guidelines to improve query performance in http://msdn.microsoft.com/en-us/library/bb934106.aspx
What I want to focus in this blog is how you can detect that the issue is Cell by Cell Calculations.
We have two main tools to troubleshoot this kind of problems, SQL Server Profiler and Performance Monitor, the recommended order is to identify that the problem is Formula Engine using the profiler and then use the Performance monitor to confirm that the query is using Cell By Cell Calculation instead of block calculation (or computation).
Here is the recommended methodology, this is not new, but I haven’t found a good reference that goes through this steps.
Step 1. Identify if bottleneck is Formula engine
Use the profiler to capture the execution of your query, it is easiest if you do this in an isolated environment but if not possible you can still filter the events from your query using the ConnectionId or some other column.
You need to add the duration for each QuerySubcube, and then subtract that total from the duration shown in the QueryEnd Event. In this example you can see that most subcubes take 0 ms, some of them 16 ms and some other that is not shown in the image was 110 ms. You can also see that the total for the query was 3,953 ms, that means that, in the Storage Engine, Analysis Services spent 142 ms and the difference 3811 ms were spent in the Formula Engine.
In conclusion, we have a Formula Engine Bottleneck, let’s check is that bottleneck is caused by cell by calculation.
The previous procedure may not scale well when you have hundreds of subcubes events or many potential queries using Cell by Cell in the same trace, in that situation you can use a procedure like this one:
Step 2. Identify if the issue is Cell by Cell Calculation
You can use Performance Monitor to identify if the issue is that the calculations is being done Cell By Cell. To be successful in this task is necessary that you run your query in an isolated environment because we have a single counter for all queries and to be sure that our query is the one causing the problems you need to execute it alone, without other concurrent queries. If your query is using Cell By Cell calculation you will see something like the following image in your query.
In the image you can see that the counter being used is “MSOLAP&InstanceName:MDX \ Total Cells Calculated” and the initial value is 0 and the value after you execute the query is a little above 1 million.
After restarting the instance we can see that a single execution of the query had to calculate more than 1 million rows. If this is the first time you do this, you don’t know if 1 million is too much or too low. I can tell you that is very high for this specific query.
Step 3. Modify your query
Modify the query using the guidelines in the links references until you stop seeing the big increments in cell calculated for your query.
In this particular case the Script was using a couple of expressions like:
Measures.Measure1 ^ 2
We changed the formula to something like:
Measures.Measure1 * Measures.Measure1
After the formula was changed in this particular case we got the following results.
You can see that the total for the query is 156 ms now, considering that the Storage Engine must have used the same time, 132 ms, it means that now the Formula Engine is taking only 24 ms.
In the performance Monitor we can see that the total number of cell calculated was 41. The query was executed after another restart of the instance.
Final Comments
This is just a basic procedure to find out what is causing the problem on your query. Modifying the query to avoid cell by cell calculation will be easy sometimes, like in this real case, and will be hard in other scenarios.
I hope this is helpful to start troubleshooting your own cases.
Hace algunas semanas me pidieron apoyo con un problema de desempeño en algunas consultas MDX.
Me mostraron lo que el cliente quería lograr, ellos necesitaban calcular algunas métricas incluyendo errores de muestra utilizando el método “Conglomerados Últimos” para calcular el error en la muestra a posteriores para muestras estratificadas. Éste método fue creado por un investigador español y fue publicado en España. Pueden encontrar la referencia aquí, http://dialnet.unirioja.es/descarga/articulo/250808.pdf
Tratar de entender el método y las fórmulas que se usan es difícil, afortunadamente el cliente ya tenía una implementación elegante de dichas fórmulas en el Script MDX usando la sentencia SCOPE y en solo unas líneas implementaron la parte más compleja de las fórmulas. Por lo tanto me enfoqué en el tema de performance en lugar de la implementación de las fórmulas.
Después de un par de horas encontré que la fórmula estaba usando calculas cell by cell en logar de cálculos por bloque, la causa era un operador (el operador “^”) y después de un pequeño cambio (multiplicar la métrica por si misma) el query mejoró de aproximadamente 30 segundos a 1 segundo.
Puedes encontrar el detalle acerca de operadores que soportan cálculos basados en bloque en el documento “Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services” encontrado en http://www.microsoft.com/en-us/download/details.aspx?id=661, también puedes encontrar algunas recomendaciones para mejorar performance de queries en http://msdn.microsoft.com/en-us/library/bb934106.aspx
El enfoque de éste blog es en cómo podemos detectar los casos en donde el problema es cálculos Cell by Cell.
Tenemos 2 herramientas que usaremos para éste propósito, una es el SQL Server Profiler y la otra es el Performance Monitor, el orden recomendado es identificar primero que el problema está en el Formula Engine y después confirmar con el Performance Monitor que la causa de que el Formula Engine esté lento son cálculos Cell By Cell.
Aquí está la metodología recomendada, esto no es nuevo, pero no he encontrado una buena referencia que cubra éstos pasos.
Paso 1. Identificar si el cuello de botella está en el Formula Engine.
Utilizar el profiler para capturar la ejecución de tu query, es más fácil si haces esto en un ambiente aislado pero si no es posible, puedes filtrar los eventos en tu query por el ConnectionId o alguna otra columna que identifique todos los eventos de tu query.
Necesitas sumar la duración de cada evento QuerySubcube y restar ese total de la duración mostrada en el evento QueryEnd. En éste ejemplo puedes ver que la mayoría de los subcubos tomó 0 ms, algunos tomaron 16ms y otro que no se ve en la imagen tomó alrededor de 110 ms. El total del query fue 3,953 ms, eso significa que Analysis Services utilizó 142 en el Storage Engine y la diferencia de 3811 se utilizó en el Formula Engine.
En conclusión, en el caso anterior tenemos un cuello de botella en el Formula Engine Bottleneck, revisemos si en éste caso es causado por cálculos cell by cell.
El procedimiento anterior puede no escalar tan bien cuando tienes cientos de subcubos o muchos queries utilizando cálculos Cell by Cell en el mismo trace, en esos casos el siguiente procedimiento puede ser más apropiado:
Paso 2. Identificar si el problema es causado por cálculos Cell by Cell
Puedes utilizar el Performance Monitor para identificar si el problema son cálculos Cell By Cell. Para ser exitoso en ésta tarea es mucho mejor que ejecutes el query en un ambiente aislado porque tenemos un contador con el total de cálculos de celdas para toda la instancia y no hay forma de separarlo por query en el Performance Monitor. La imagen de abajo muestra cómo se ve el ejemplo nuestro.
En la imagen puedes ver que el contador usado es “MSOLAP&InstanceName:MDX \ Total Cells Calculated” y el valor inicial es 0 y el valor después de ejecutar el query es superior a 1 millón.
Los resultados anteriores fueron después de reiniciar la instancia y una sola ejecución del query generó más de un millón de celdas calculadas. Si ésta es la primera vez que haces esto no sabes si 1 millón es muy alto o es bajo. Puedo asegurarte que para éste query es un número bastante alto.
Paso 3. Modificar tu query
Modificar el query utilizando las recomendaciones en los links mencionados anteriormente hasta que dejes de ver el gran incremento en número de celdas calculadas para tu query.
En éste caso particular el Script MDX estaba usando algunas expresiones del tipo:
Cambiamos la formula a algo como:
Después de que la formula fue cambiada obtuvimos los siguientes resultados.
Puedes ver que el total del query es 156 ms, considerando que el Storage Engine debió usar el mismo tiempo, 132 ms, significa que el Formula Engine tomó aproximadamente 24 ms.
En el Performance Monitor podemos ver que el total de celdas calculadas fue 41. El query fue ejecutado después de que se reinició la instancia.
Comentarios Finales
Esto es solo el procedimiento básico para encontrar si los cálculos cell by cell están causando problemas en tu ambiente. Las modificaciones al query para evitar cálculos cell by cell puede ser fácil algunas veces, como en éste caso real, o muy difícil en otros escenarios.
Espero esto sea útil para que puedan empezar a solucionar sus propios casos.
In one of my regular customers, they are begging the SQL Server 2012 Migration, at the installation process for a SQL Server 2012 Instance on a Windows Server 2008R2 Cluster, they found an error while adding a node to de SQL Instance.
This error didn’t allow them to go forward to add the node on the SQL Instance, there are a few posible causes to check.
In this case we checked the first and second probable causes, but the error still appear.
After that we checked the third probable cause and we observed that the IP was been resolved to the NETBIOS name and not to the FQDN name, so we fix that problem, and we retried the add node process to the SQL Instance, this time was successful.
En uno de mis clientes regulares, están iniciando la migración hacia SQL Server 2012, al momento de la Instalación de una Instancia de SQL Server 2012 sobre un Windows Cluster de Windows Server 2008R2, se presentó el siguiente error durante el proceso de añadir un nodo a la Instancia de SQL.
Este error no permite seguir con el procedimiento de añadir un nodo a la Instancia de SQL en el Cluster, hay un par de motivos por el cual este error puede aparecer:
En este caso se revisó la primera y segunda posible causa, sin embargo el error todavía seguía apareciendo.
Por tanto se revisó la tercera causa y se pudo observar que las respuestas de la resolución de nombre devolvían el nombre NETBIOS y no el nombre FQDN, luego de resolver este problema, se reintento el proceso de añadir nodo a la Instancia de SQL en el cluster de forma satisfactoria.
Em ambientes que temos soluções customizadas para o SharePoint 2010, é muito comum aparecer no Heath Analyzer a mensagem de erro a seguir:
Assembly [My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cfc9a4dcd383ae1e] is referenced in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this assembly.
Na maioria dos casos esse erro é gerado por algum Event Receiver problemático, ou seja, que tenha sido esquecido de remover da solução customizada, ou outro problema relacionado com a desativação ou retração da solução.
Neste post eu quero compartilhar com vocês um script Power Shell que pode ajudá-los a remover esse event receiver problemático.
Leia o resto deste post
Duración: 1hr.
Tema: Power Pivot y Power View – Personal BI.
Descripción del tema: En ésta sesión se presentarán las funcionalidades y escenarios en los que éstas dos (2) componentes de Office y SQL encajan en una solución de BI y brindan al usuario final la libertad de explotar la información disponible en la empresa de una manera más eficiente.
Objetivo: Dar a conocer cómo funcionan Power Pivot y Power View, que nuevas funcionalidades se esperan y como pueden empezar a utilizarlos.
Presentador: Rubén González
En esta sesión hablaremos de algunas de las Mejores Practicas en diferentes niveles de SQL Server para obtener un buen rendimiento en SQL Server.
Uno de los hallazgos más comunes en el Health Analyzer, cuando se desarrollan soluciones a la medida en SharePoint 2010 es el siguiente:
La mayoría de las veces el hallazgo es acerca de Recibidores de Eventos que no han sido correctamente desinstalados, ya sea en la desactvación o eliminación de la solución.
En esta entrada de blog pretendo compartir con ustedes un script de Power Shell con el don de ayudar a identificar y remover estos Recibidores de Eventos corruptos.
El script contiene las siguientes funciones:
Delete-MissingAssembly: Esta es la función principal que recorre cada posible contenedor en la base de datos que pueda tener Recibidores de Eventos, esto quiere decir Colección de listas, Sitios o Listas.
Remove-EventReceiver: Esta función revisa si un contenedor de Recibidores de Eventos tiene alguno con el nombre de assembly que se le pase como parámetro, y trata de eliminarlo.
Las 2 funciones tienen un parámetro (ReportOnly) que permite definir si se quiere eliminar o no el Recibidor de Evento encontrado.
function Delete-MissingAssembly($ContentDb, $Assembly, [switch]$ReportOnly)
{
[bool]$report = $false
if ($ReportOnly) { $report = $true }
$database = Get-SPContentDatabase | ?{$_.Name -eq $ContentDb}
foreach($site in $database.Sites)
Remove-EventReceiver -ERContainer $site -Assembly $Assembly -ReportOnly $report
foreach($web in $site.AllWebs)
Remove-EventReceiver -ERContainer $web -Assembly $Assembly -ReportOnly $report
foreach($list in $web.Lists)
Remove-EventReceiver -ERContainer $list -Assembly $Assembly -ReportOnly $report
}
function Remove-EventReceiver($ERContainer, $Assembly, $ReportOnly)
foreach($er in $ERContainer.EventReceivers)
if($er.Assembly -eq $Assembly)
Write-Host "Event Receiver with Id[" $er.Id "], Name[" $er.Name "] and Type [" $er.Type "] found in [" $ERContainer.Url $ERContainer.DefaultViewUrl "]."
if($ReportOnly -eq $false)
Write-Host "Try to delete the receiver:"
$er.Delete()
Write-Host "ER deleted."
Después de que usted guarde este script en un archivo PS1 y lo importe en Power Shell (Ejemplo: Import-Module .\MissingEV.PS1), usted puede ejecutar el script de esta forma:
Delete-MissingAssembly -ContentDb WSS_Content -Assembly "My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cfc9a4dcd383ae1e" -ReportOnly
La salida de ejecución del comando puede ser:
Como se puede ver en la salida de Power Shell, muestra el Id, Nombre, Tipo y ubicación del Recibidor de Eventos, donde usted puede decidir si borrar o no este, por lo contrario debería utilizar otra herramienta o directamente con PS.
Espero que esta entrada sirva para resolver los típicos problemas del hallazgo “Missing server dependencies” en el Health Analyzer.
One of the most common issues in the Health Analyzer when you deploy custom solutions in your SharePoint 2010 environment, is this one:
Most of the times this issue is regarding some bad Event Receivers that you forgot to remove before you delete the custom solution, or another problem related with the feature deactivation and solution retraction.
In this post I want to share with you a Power Shell script that can help you to remove this kind of bad Event Receivers.
The following script contains 2 functions:
Delete-MissingAssembly: This is the main function that goes through every possible container in the specific database that can host an Event Receiver, it means Site, Web or List.
Remove-EventReceiver: This function check if the event receiver container has any event receiver with the specific assembly name, shows his information and try to delete it.
Also the 2 functions has a parameter to allow directly delete the event receiver or only shows in the screen the information regarding the ER.
After you save this script in a PS1 file and import it (Example: Import-Module .\MissingEV.PS1), you can use the function in the following way:
And the output could be:
As you can see the output of the Power Shell shows the Id, Name, Type and location of the specific event Receiver, you can decide if remove it with this script or access through PS or a 3rd tool to remove it.
Hope this helped you in the typically Missing server side dependencies issue in the Health Analyzer.
Lendo um post no fórum do MSDN com o título Recuperar ID de pasta na Biblioteca usando Web Services fiquei curioso com o problema reportado, que era conseguir consultar uma pasta do SharePoint passando o nome dela e retornando o ID, utilizando o webservice Lists.ASMX.
Este post tem um exemplo de como implementar esta necessidade.
Leia o resto deste post »
O workflow do SharePoint 2010 é muito rico em detalhes que muitas vezes são inexplorados. Um deles é o processo de aprovação, que nos permite customizar a interação do usuário com as tarefas de workflow de uma forma mais rica.
Neste post vou mostrar como editar o e-mail de tarefa atribuída que o workflow envia, mas o conteúdo deste post pode ser utilizado em outras customizações desta atividade.
Como ustedes deben recordar en SharePoint 2010 usted podía utilizar la interfaz gráfica para crear o re configurar su topología de Búsqueda empresarial, utilizando la administración de la aplicación de servicio de Búsqueda. En dicha interfaz gráfica usted puede crear, editar o remover cualquiera de los siguientes componentes:
Y era muy fácil para los administradores utilizar cualquiera de los servidores de la graja y de esta forma configurar la mejor topología de Búsqueda empresarial basados en sus requerimientos de negocio.
Una de las cosas que las personas más me comentan es que utilizar la interfaz gráfica para configurar la topología es realmente fácil, pero si uno comete algún error configurando algún parámetro o tiene algún otro problema en la granja, y al finalizar de configurar la topología empresarial de Búsqueda, y hacer clic en el botón de aplicar los cambios, luego de un buen rato aparece un error y las mayoría de los cambios realizados no se mantienen.
El anterior problema es una buena razón para configurar su topología empresarial de Búsqueda con Power Shell, porque usted tiene toda la flexibilidad de crear y re configurar los componentes, y esto puede ayudar a identificar problemas en su granja o topología antes de que finalice de configurar en su totalidad esta.
También es importante mencionar que algunos administradores de SharePoint le temen administrar SharePoint con Power Shell, por qué piensas que están pasándose al lado de desarrollo y ellos solo quieren ser profesionales de infraestructura. Pero lo que deben saber es que Microsoft está invirtiendo en utilizar Power Shell en la mayoría de sus productos con el fin de ofrecer una sola forma de administrarlos a todos y facilitar y flexibilizar las tareas de infraestructura. Yo espero que este blog ayude a aquellos administradores a quitarse ese concepto de la mente.
Es de saber para las personas que ya están trabajando con SharePoint 2013, que la única vía para configurar la topología de búsqueda es atreves de Power Shell y sus cmdlets disponibles para crear los nuevo y poderosos componentes del nuevo servicio empresarial de Búsqueda de SharePoint 2013.
El propósito de esta entrada de blog es mostrar algunos ejemplos de cómo crear una topología de Búsqueda empresarial en SharePoint 2013, obviamente utilizando Power Shell, pero no solo mencionando que cmdlets utilizar, sino también como podrían automatizar esta labor y así poder repetir estos pasos las veces que sean necesarias y utilizarlos en otras implementaciones de SharePoint 2013, y adicionalmente ayudar a los administradores de SharePoint a perder ese miedo en utilizar Power Shell para administrar SharePoint.
Todos los cmdlets utilizados en esta entrada de blog están basados en el siguiente documento de TechNet:
Manage search components in SharePoint Server 2013
http://technet.microsoft.com/en-us/library/jj862354.aspx
Si usted no ha leído el anterior documento, yo recomiendo que lo haga o lo tome como referencia para la lectura de esta entrada.
A continuación voy a resumir los pasos para crea una nueva topología de Búsqueda en SharePoint 2013, y los cuales son mencionados en el anterior documento:
Como se puede ver existen varios pasos a realizar y por lo tanto varios comandos de Power Shell deben ser ejecutados, por esta razón he creado las siguientes funciones que nos permitirán facilitar la creación de la topología de búsqueda.
GetOrStartSearchServiceInstance
La siguiente función permite identificar si un servidor tiene el servicio de búsqueda indicado, si no es así lo inicia.
function GetOrStartSearchServiceInstance($Server)
$startInstance = $false
$serverIns = Get-SPEnterpriseSearchServiceInstance -Identity $Server
if($serverIns -ne $null)
if($serverIns.Status -ne "Online")
$startInstance = $true
else
if($startInstance)
$serverIns = Start-SPEnterpriseSearchServiceInstance -Identity $serverIns
return $serverIns
En este caso la forma de llamar esta función será:
GetOrStartSearchServiceInstance -Server “<server name>”
Como pudo ver en el documento de TechNet, para adicionar y remover un componente de búsqueda se utilizan los siguientes cmdlets:
En el caso de New-SPEnterpriseSearch<SearchComponent>Component, si usted entra en detalle a ver que parámetros acepta, es posible para todos los cmdlets proveer 2 parámetros básicos los cuales son la topología y la instancia de servicio (es decir el servidor), es por esto que he creado la siguiente función la cual permite crear cualquiera de los componentes anteriormente mencionados en la cantidad de servidores necesarios.
Set-SPSearchComponents
Esta función necesita los siguientes parámetros:
function Set-SPSearchComponents($ServerType, $ServersStringArray, $Topology)
#Check if is a valid type of search component
$validTypes = ("Admin", "AnalyticsProcessing", "ContentProcessing", "Crawl", "QueryProcessing")
if($validTypes.Contains($ServerType) -ne $true)
throw "ServerType is not valid."
#Check server by server is need to Remove or Add
$ServerType += "Component"
$currentServers = Get-SPEnterpriseSearchComponent -SearchTopology $Topology | ?{$_.GetType().Name -eq $ServerType}
#Remove components
foreach($component in $currentServers)
Remove-SPEnterpriseSearchComponent -Identity $component -SearchTopology $Topology #-Confirm $true
#Add Components
foreach($server in $ServersStringArray.Split(","))
#Check in search service instance is started, otherwise start it
$serIns = GetOrStartSearchServiceInstance -Server $server
switch($ServerType)
"AdminComponent" {New-SPEnterpriseSearchAdminComponent -SearchTopology $newTop -SearchServiceInstance $serIns}
"AnalyticsProcessingComponent" {New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}
"ContentProcessingComponent" {New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}
"CrawlComponent" {New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTop -SearchServiceInstance $serIns}
"QueryProcessingComponent" {New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTop -SearchServiceInstance $serIns}
#Show in the output the search components of the topology to see the modificatios made on.
Get-SPEnterpriseSearchComponent -SearchTopology $Topology
Un ejemplo para invocar esta función podria ser el siguiente:
Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray “server1,server3” -Topology $newTop
Finalmente para dar un gran ejemplo de cómo crear totalmente una topología empresarial de Búsqueda en SharePoint 2013, he creado la siguiente función, la cual hace uso de las anteriores.
New-SPSearchTopology
Para usar esta función se deben proveer los siguientes parámetros:
function New-SPSearchTopology($AdminServers, $AnalyticsServers, $ContentServers, $CrawlServers, $QueryServers)
$servers = $AdminServers + "," + $AnalyticsServers + "," + $ContentServers + "," + $CrawlServers + "," + $QueryServers
#Check the existence of the servers
foreach($server in $servers.Split(","))
Get-SPServer $server -ErrorAction Stop
#Initialize variables
$ssa = Get-SPEnterpriseSearchServiceApplication
#Clone search topology
$activeTop = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active
$newTop = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone –SearchTopology $activeTop
#Admin component
Set-SPSearchComponents -ServerType "Admin" -ServersStringArray $AdminServers -Topology $newTop
#Analytics servers
Set-SPSearchComponents -ServerType "AnalyticsProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop
#Content
Set-SPSearchComponents -ServerType "ContentProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop
#Crawl
Set-SPSearchComponents -ServerType "Crawl" -ServersStringArray $AnalyticsServers -Topology $newTop
#Query
Set-SPSearchComponents -ServerType "QueryProcessing" -ServersStringArray $AnalyticsServers -Topology $newTop
#Active Topology
Set-SPEnterpriseSearchTopology -Identity $newTop
New-SPSearchTopology –AdminServers “server1,server2” –AnalyticsServers “server1,server3” –ContentServers “server2,server4” –CrawlServers “server5,server6” –QueryServers “server7,server8,server9”
Espero que esta entrada haya sido de ayuda para crear su nueva topología empresarial de Búsqueda en SharePoint 2013, y recuerde que no todas las consideraciones acerca del servicio empresarial de Búsqueda de SharePoint 2013 han sido tomadas en cuenta en este artículo, en el futuro espero escribirles acerca de:
As you may remember in SharePoint 2010 you had a specific user interface to create and reconfigure your enterprise Search topology, in the Search Service applications management. There you can create, edit and remove the following components:
And it was very easy by the administrator to use any server in their farm to configure the best enterprise Search topology for their business requirements.
One thing than many people said to me was that the configuration was very easy with the UI, but if you put something wrong or your farm have any issue, when you finished to reconfigure your enterprise search topology, and you click in the button to apply all the changes, it takes a while and gives you an error and also you lose the majority of the changes that you made before.
The above problem was a good reason to configure your enterprise search topology with Power Shell, because you have the flexibility to create and reconfigure the components one by one, it help you to identify issues in your farm regarding the search service before finish to define your enterprise search topology.
Also some Share Points administrators have afraid to manage SharePoint with Power Shell, because are thinking that are writing scripts so are developing things, and they may be don’t want to be a developers, only IT infrastructure guys. But you must to know that the reason that Microsoft are integrating Power Shell in all our products is to try to standardize the way that you can manage the different services. I hope this blog could help to those SharePoint administrators that have this concept in mind.
Now, for the people that are working with SharePoint 2013, knows that the only way to create or reconfigure your enterprise Search Topology is using the Power Shell cmdlets created for the new and powerful components of the SharePoint 2013 Enterprise Search Service Application.
The propose of this blog entry is to show you some examples to create an enterprise Search topology in SharePoint 2013, also with Power Shell, but not only to tell you the specific cmdlets that you must or can use to do this job, my objective is to try to automatize this work creating scripts that you can use in your different implementations of SharePoint 2013, also this can help the SharePoint administrators to lose their afraid when are using Power Shell to manage SharePoint.
All the cmdlets that I use in this entry are based in the following TechNet document:
If you didn’t read the above document, I recommend to you to do it or take as a reference for the cmdlets that you are going to see here.
I’m going to start to summarize the basics steps that you must to do when you want to create a new Enterprise search topology:
As you can see there are some steps that you must to do and in some cases you must to repeat them, for this reason I created the following power shell functions to help to create our Search topology.
The following function help us to check if the search service instance is started in a specific sever and retrieve the reference to it, or start the service instances in the case that is wasn’t started.
In this case you provide to the function a server name and the function retrieve a search service instance, you must to call it in the following way:
As you can saw in the TechNet document, to add and remove the search component we use the following functions:
In the case of New-SPEnterpriseSearch<SearchComponent>Component, you can dig in deep and see that you can use the same basic parameters: the Search topology and the search service instance, for that reason I created the following function to help create and remove the specific components on a the specific servers.
This functions needs the following parameters:
An example to use this function could be:
Finally to give you a mainly example to create a SharePoint 2013 Enterprise Search Topology, I written the following function using the functions mentioned above.
To use this function must to pass the following parameters:
I hope this post could help you to create your new SharePoint 2013 Enterprise Search Topology, and remember that not all the Enterprise Search considerations are taken on this scripts, in the future I going to write about how to change the following characteristics: