SharePoint SPoiler
Un sitio de Sharepoint donde intentamos explicar de manera amena posibles soluciones a problemas que se dan comúnmente en el uso de la herramienta Sharepoint, así como otras aplicaciones que conviven con ella, como puede ser Powershell o Nintex Forms/Workflows
5.10.18
11.9.18
11.9.17
Cómo cambiar texto "Sharepoint" esquina superior
Por defecto, la aplicación de Sharepoint muestra en la esquina superior izquierda su nombre, algo que puede resultar poco estético a la hora de desarrollar una aplicación.
Se puede cambiar esto ya sea añadiendo una imagen, cambiando el texto, poniendo un logo con link a la home... Se puede hacer de la siguiente forma:
1. Acceder al servidor de Sharepoint.
2. Abrir PowerShell como Administrador.
3. Ejecutar el siguiente código (modificar texto en rojo para que se adapte a la aplicación):
Add-PSSnapin "Microsoft.Sharepoint.Powershell"
$webApp =
Get-SPWebApplication https://www.estaeslaurldelsitio.es
$webApp.SuiteBarBrandingElementHtml = '<a
href="/" ><img
alt="Home" src="/rutadelaimagen/logo.png"/></a>'
$webApp.Update()
15.2.17
Usuario con control total en una página no puede guardar los cambios
A
veces, puede darse la circunstancia que un usuario de SharePoint tenga permisos
de Control Total en una página en concreto dentro de un site, pero en este
mismo site sus permisos son de Lectura.
Este
caso puede verse como una solución para un usuario que sólo debe editar y
modificar una página en concreto, pero ya sabemos que otorgar permisos de
Control Total sólo para la edición de algunas páginas no es una buena práctica.
El
usuario podrá editar la página sin ningún problema, pero cuando intente guardar
los cambios que ha realizado estos no se verán reflejados y SharePoint no dará
ningún tipo de error.
El
fallo se debe a la forma que tiene SharePoint de heredar permisos. No hay
problema en romper la herencia de permisos entre sitios y bibliotecas, ya que
hay veces que es totalmente necesario. El problema que se está dando en este
caso es que el permiso más restrictivo (Lectura) está a nivel de sitio, y
después un permiso más flexible (Control Total) a nivel de archivo (página),
pero en este caso en concreto el error viene a la hora de Guardar los cambios.
SharePoint
no podrá salvar estos cambios ya que la página se guarda a nivel de sitio (sitio/paginas/pagina.aspx)
y este usuario en concreto no tiene permisos de edición en este nivel. Es por
esto que al intentar guardar los cambios no se vean, puesto que realmente no
los está guardando por falta de permisos.
La
solución para este tipo de casos sería asignar permisos de Diseño a nivel de
sitio y de página. Con este tipo de permiso el usuario podrá guardar sin
problema sus cambios ya que tiene permisos de edición tanto a nivel de site
como de archivo.
2.1.17
El archivo hosts para realizar pruebas de funcionamiento
¿Quién no ha tenido la necesidad de modificar el archivo hosts dentro de su máquina para realizar pruebas de funcionamiento de una aplicación antes de salir a producción o cambios que hayas realizado y quieres probarlos antes de ponerlos online?
Para ello se puede utilizar el archivo hosts que proporciona el sistema operativo Windows. Este archivo es utilizado por Windows para almacenar la relación entre los dominios de Internet y las direcciones IP, de manera que desde tu máquina puedes acceder a una dirección IP o un dominio.
El archivo hosts se encuentra en el siguiente path:
C:\Windows\System32\drivers\etc\hosts
Si necesitas modificar este archivo es tan simple como poner en la última línea la IP donde quieres conectar y el dominio que la relaciona. Por ejemplo:
1xx.1xx.xx.x www.midominio.com
Con esta línea dentro de nuestro archivo hosts podemos escribir dentro de nuestro navegador de Internet la dirección http://www.midominio.com (en el archivo hosts no hay que poner http://) y el propio navegador nos redirigirá a la IP que hemos colocado en el archivo hosts, de manera que estamos realizando una redirección de nuestra propia máquina.
2.12.16
¿Cómo averiguar qué error te está dando en Sharepoint?
¿No os ha pasado nunca que os ha llegado una incidencia de que a un usuario le ha dado un fallo en Sharepoint sin más información al respecto?
Si al menos nos enviaran la hora del fallo o incluso el identificador del mismo, podríamos empezar a buscar en los logs de Sharepoint de cada uno de los servidores de la granja (siempre que tengamos más de un servidor frontal o más de un servidor de aplicaciones) para encontrar cuál ha podido ser el error.
Dentro de SharePoint 2013 hay una manera de ahorrarte mucho tiempo en lugar de tener que buscar en qué servidor se ha guardado el log que ha almacenado información sobre el error.
Para ello puedes crear un archivo log específico donde se escriban todas las entradas de los archivos log (en inglés Unified Logging Service, más conocido como ULS) de todos los servidores de la granja que hayan almacenado información sobre error.
Para ello, primero necesitamos conocer el Correlation ID que ha dado en el error (cuando Sharepoint devuelve un error, al desplegar los detalles sobre el error hay un texto muy largo, compuesto por número, letras y guiones, que indica el valor del error (por ejemplo, 6b553c9d-2965-b0f1-93c3-4971554d734b).
Con esta información, vamos a un servidor de la granja a ejecutar la consola de Sharepoint donde usaremos el comando Merge-SPLogFile para construir el archivo log con toda la información referente al error que se haya almacenado en la granja de servidores de SharePoint.
Un posible ejemplo para compilar toda la información en un archivo que nosotros creemos sería la siguiente:
C:\Users\yo> Merge-SPLogFile -Path "F:\Logs\FarmMergedLog.log" -Overwrite -Correlation "6b553c9d-2965-b0f1-93c3-4971554d734b" -StartTime "02/12/2016 13:00"
Para ver el log yo utilizo el programa ULS Viewer aunque hay muchos programas para verlo.
Podéis encontrar más información sobre este comando en el siguiente enlace.
Un saludo
Suscribirse a:
Entradas (Atom)