saabbir
Acabo de experimentar un problema extraño hoy. Mi servidor de informes de PowerBI (en las instalaciones) estaba previamente en un SSL de autocertificación antes. Tengo informes que se ejecutan en modo importado desde un servidor SQL remoto que no acepta conexión cifrada. Todo dentro del mismo dominio. Actualicé SSL a SAN SSL el otro día en el servidor de informes. Toda la conexión de la fuente de datos sigue siendo la misma (SQL Server remoto no SSL). Por cierto, estoy ejecutando el servidor de informes de mayo de 2021. Esta mañana, uno de los colegas informó que los datos no se actualizaron. Al verificar, vi que la actualización del programa falló. Y traté de agregar un programa de actualización en otro informe PBIX del modo de importación. Tengo un gran gordo «Algo salió mal». La fuente de datos tiene credenciales básicas y en la página de la fuente de datos, la conexión de prueba es exitosa con las credenciales básicas de inicio de sesión de SQL. Pero cada vez que intento agregar un programa de actualización, aparece el mismo error. Continué revisando el registro y detallado. Tengo «Error 401». Error de detalle, si a alguien le interesa:
2021-07-07 00:47:55.7026|ERROR|63|Se produjo una excepción OData: System.Net.WebException: la solicitud falló con el estado HTTP 401: no autorizado. en System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(mensaje SoapClientMessage, respuesta WebResponse, Stream responseStream, Boolean asyncCall) en System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parámetros) en Microsoft.SqlServer.ReportingServices2010.ReportingService2010.CreateCacheRefreshPlan(String ItemPath, String Description, String EventType, String MatchData, ParameterValue[] Parámetros) en Microsoft.SqlServer.ReportingServices2010.RSConnection2010.<>c__DisplayClass136_0.b__0() en Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SoapMethodWrapper1.ExecuteMethod(Boolean setConnectionProtocol) en Microsoft.SqlServer.ReportingServices2010.RSConnection2010. , String eventType, String matchData, ParameterValue[] parámetros) en Microsoft.ReportingServices.Portal.Services.SoapProxy.SoapRS2010Proxy.<>c__DisplayClass19_0.
b__0() en Microsoft.ReportingServices.Portal.Services.SoapProxy.SoapAuthenticationHelper.ExecuteWithWindowsAuth[TReturn](SoapHttpClientProtocol soapClient, IPrincipal userPrincipal, Func1 func) en Microsoft.ReportingServices.Portal.Repositories.SubscriptionService.CreateCacheRefreshPlan(IPrincipal userPrincipal, CacheRefreshPlan cacherefreshPlan) en Microsoft.ReportingServices.Portal.ODataWebApi.V2.Controllers.CacheRefreshPlansController.AddEntity(CacheRefreshPlan entidad) Microsoft.ReportingServices.Portal.ODataWebApi.Controllers.Reflection.EntitySetReflectionODataController1.Post(ODataPath oDataPath, valor T) en lambda_method(Cierre, Objeto, Objeto[] ) en System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2. b__2(Instancia de objeto, Objeto[] methodParameters) en System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, argumentos IDictionary2, CancellationToken cancelationToken) — Fin del seguimiento de la pila desde la ubicación anterior donde se lanzó la excepción — en System.Runtime.ExceptionServices.ExceptionDispatchInfo. Throw() en System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Tarea de tareas) en System.Web.Http.Controllers.ApiControllerActionInvoker.d__1.MoveNext() — Fin del seguimiento de la pila desde la ubicación anterior donde se lanzó la excepción — en System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() en System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(tarea) en System.Web.Http.Controllers.ActionFilterResult.d__5.MoveNext() — Fin del seguimiento de la pila desde ubicación anterior donde se lanzó la excepción — en System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() en System.Runtime.CompilerServices.TaskAw aiter.HandleNonSuccessAndDebuggerNotification(tarea) en System.Web.Http.Controllers.ExceptionFilterResult.d__6.MoveNext().| ID de solicitud = s_9b953a1c-bc48-41f3-ad5b-12e903990663
Es posible que ahora haya leído el 95% de los foros/blogs/soluciones/documentaciones sin suerte.
Así que pensé, intentemos hacerlo a través de HTTP (puerto 80) en lugar de HTTPS (puerto 443). Y funcionó como un encanto. Por cierto, de forma predeterminada, se elimina el enlace HTTP, solo se permite HTTPS. He marcado «La conexión cifrada está deshabilitada» en la configuración de la fuente de datos en el escritorio de PowerBI y actualicé y volví a implementar. El mismo problema con HTTPS, pero funciona bien con HTTP.
¿Alguien tiene una solución/arreglo permanente para este problema? Porque no se permite ejecutar el servidor de informes en HTTP. Intenté reiniciar ambas instancias, cambiando los valores de registro mencionados en Internet, nada funcionó. Además, tenemos Kerberos habilitado y nuestra autenticación de Windows funciona perfectamente bien para fuentes de datos remotas de SQL Server.
Gracias a todos por leer y usar su espacio cerebral. Qué tengas buenas noches.
Nota: el foro eliminó algunas partes del mensaje de error. No me deja enviarlos.
saabbir
Hola a todos,
Gracias por su apoyo y tiempo. Ahora configuré otra máquina virtual con exactamente la misma configuración, excepto que el servidor SQL está habilitado para TLS. Dejé deliberadamente «Forzar cifrado = Falso». Todo está funcionando a las mil maravillas.
He probado los siguientes escenarios:
- SQL no encriptado + HTTP RS = Funciona
- SQL no encriptado + HTTPS RS = No funciona
- SQL cifrado + HTTP RS = No probado
- SQL cifrado + HTTPS RS = Funciona
Algunas cosas para recordar: no olvide agregar los SPN, usar FQDN es importante y asegúrese de que el usuario tenga al menos permiso de lector de datos en las bases de datos SQL.
Espero que esto ayude.
Entorno: Windows Server 2019 Enterprise, SQL Server 2017 Enterprise Core, PowerBI Report Server, mayo de 2021.
Gracias
Sabbir
saabbir
Hola a todos,
Gracias por su apoyo y tiempo. Ahora configuré otra máquina virtual con exactamente la misma configuración, excepto que el servidor SQL está habilitado para TLS. Dejé deliberadamente «Forzar cifrado = Falso». Todo está funcionando a las mil maravillas.
He probado los siguientes escenarios:
- SQL no encriptado + HTTP RS = Funciona
- SQL no encriptado + HTTPS RS = No funciona
- SQL cifrado + HTTP RS = No probado
- SQL cifrado + HTTPS RS = Funciona
Algunas cosas para recordar: no olvide agregar los SPN, usar FQDN es importante y asegúrese de que el usuario tenga al menos permiso de lector de datos en las bases de datos SQL.
Espero que esto ayude.
Entorno: Windows Server 2019 Enterprise, SQL Server 2017 Enterprise Core, PowerBI Report Server, mayo de 2021.
Gracias
Sabbir
v-deddai1-msft
Hola @saabbir,
Consulte también https://docs.microsoft.com/en-us/sql/reporting-services/security/configure-ssl-connections-on-a-nati…
Si esta publicación es útil, considere aceptarla como la solución para ayudar a los otros miembros a encontrarla más rápidamente.
Atentamente,
dai demon
v-deddai1-msft
Hola @saabbir,
Intente cambiar la cuenta de servicio. de «Cuenta de servicio virtual» a «Cuenta de dominio». Y para kerberos, debe registrar spn en la cuenta de dominio.
Para programar la actualización de un informe, la cuenta de ejecución debe tener permisos de «usuario del sistema». Asegúrese de que el servidor powerbi cog->configuración->configuración del sitio->seguridad esté dando acceso a ese usuario
Y también verifique si el usuario que solía conectar a la base de datos sql tiene permiso para crear un trabajo de agente.
Aquí hay una publicación similar: https://community.powerbi.com/t5/Report-Server/Power-Bi-report-server-was-unable-to-create-a-schedul…
Si esta publicación le ayuda, considere aceptarla como la solución para ayudar a los otros miembros a encontrarla más rápidamente.
Atentamente,
dai demon
saabbir
En respuesta a v-deddai1-msft
Hola @v-deddai1-msft,
Perdón por mi respuesta tardía y muchas gracias por tomarse el tiempo para encontrar una solución a mi problema. Realmente lo aprecio.
En nuestro entorno, todo se ejecuta con una cuenta de administrador de dominio (puede adivinar, tiene más poder del que necesita). Los SPN de Kerberos también están registrados. HTTPS faltaba antes en la lista SPN, ya lo he agregado antes de publicar aquí. No funcionó.
La misma cuenta de administrador de dominio tiene permisos de Administrador del sistema y Usuario del sistema en la configuración del sitio PBIRS.
La cuenta de servicio es administrador del sistema en todos los servidores SQL, por lo que tiene permiso para crear trabajos de agente. La cuenta básica (inicio de sesión de SQL Server) que se utiliza para conectarse a la fuente de datos solo tiene permiso de lectura de datos. La razón por la que creo que dar este permiso de usuario básico para crear un trabajo de agente no funcionará es que exactamente la misma configuración funciona cuando habilito http e intento crear los trabajos programados a través de http://ServerName/reports (en lugar de https://ServerName/ informes). Supongo que cuando PBIRS intenta conectarse a la fuente de datos desde la URL https, intenta usar una conexión cifrada aunque en el uso de PBIX el cifrado no está marcado (la actualización de datos de PBIX funciona al 100% y sin errores).
En algún momento probaré mi teoría habilitando el cifrado en uno de los servidores SQL e intentaré crear una actualización programada de https PBIRS al servidor https SQL. Actualizaré el foro una vez que lo haga.
Muchas gracias de nuevo y agradezco su ayuda.
Saludos
Sabbir
