Hello all,
I just found the next link
Where you have published the download of hundreds of Ebook related to several technologies including …
I hope that you find this useful.
Hola a tod@s,
Acabo de ver este link
donde se pueden descargar cientos de Ebooks sobre las más variadas tecnologías incluyendo …
Espero que os resulte de utilidad.
One of my colleagues, Alvaro Minguez Horcajada made an impressive analysis about how collection are managed on ConfigMgr 1610 and I would like to share his discoveries here as I think that this will be really handy for any SCCM administrator.
After his deep analysis he found that we have 4 types of evaluation:
Primary – when a collection update is triggered by a schedule
Auxiliary – manual update for a collection with dependent collections;
Single – manual update for a collection with no dependent collections;
Express – incremental collection evaluation.
These types of evaluation only matter in order to give priority of what evaluation will be evaluated first, but the process for evaluation is the same for all of them.
Process of evaluation:
Incremental evaluation-> incremental evaluation will only modify INCREMENTAL collections, so if a incremental collection is related to a non incremental collection, then the non incremental collection will not change until a manual or scheduled update is performed.
Manual and scheduled evaluation-> Manual and scheduled evaluation are the same. This evaluations create a graph of all the collections affected by the update of the collection. This includes collections limited by the evaluated collection and collections that have included the collection itself.
The process starts evaluating the first collection and, if anything change, continues evaluating the rest of the graph.
Important: if a collection included inside this collection is modified, then the first collection won’t be updated because first goes the main updating collection.
Important: only users ADDED will trigger a cascade update. If we REMOVE a user from one collection this will trigger no action/evaluation.
Important: in devices, adding or removing will trigger a cascade update.
I hope that this information is useful for you.
Uno de mis colegas, Alvaro Minguez Horcajada, hizo un impresionante análisis sobre cómo se gestionan las colecciones en ConfigMgr 1610 y me gustaría compartir sus descubrimientos aquí, ya que creo que esto será muy útil para cualquier administrador de SCCM.
Después de su profundo análisis, encontró que tenemos 4 tipos de evaluación:
Primaria – cuando una actualización de colección se activa mediante un programa
Auxiliar – actualización manual para una colección con colecciones dependientes;
Única – Actualización manual para una colección sin colecciones dependientes;
Express – evaluación de la colección incremental.
Estos tipos de evaluación sólo importan para dar prioridad a la evaluación que se lanzará primero, pero el proceso de evaluación es el mismo para todos ellos.
Proceso de evaluación:
Evaluación incremental-> evaluación incremental sólo modificará las colecciones INCREMENTALES, por lo que si una colección incremental está relacionada con una colección no incremental, la colección no incremental no cambiará hasta que se realice una actualización manual o programada.
Evaluación manual y programada-> La evaluación manual y programada es la misma. Estas evaluaciones crean un gráfico de todas las colecciones afectadas por la actualización de la colección. Esto incluye las colecciones limitadas por la colección evaluada y las colecciones que se han incluido en la colección en sí.
El proceso comienza a evaluar la primera colección y, si es que algo cambia, continúa evaluando el resto del gráfico.
Importante: si se modifica una colección incluida dentro de esta colección, la primera colección no se actualizará porque primero se va a la colección principal de actualización.
Importante: sólo los usuarios AÑADIDOS activarán una actualización en cascada. Si RETIRAMOS a un usuario de una colección esto no activará ninguna acción/evaluación.
Importante: en las colecciones de dispositivos, agregar o quitar activará una actualización en cascada.
Espero que esta información sea de utilidad.
Hello again.
There are two WMI methods in the smsprovider for managing members of a collection (accessible through a script or powershell):
AddMembershipRule
DeleteMembershipRule
These are usually added in scripts to automate the inclusion of machines in collections, usually during the installation of the operating system in the execution of the task sequence.
But when we have a secure environment in ConfigMgr we can find events such as the following when running, visible in the smsprovider, which controls access to objects in the database:
ExecMethodAsync: SMS_Collection.CollectionID = “SIT00001” :: AddMembershipRule SMS Provider date 2:57:12 PM 18128 (0x46D0)
Requested class = SMS_Collection SMS Provider date 2:57:12 PM 18128 (0x46D0)
Requested num keys = 1 SMS Provider date 2:57:12 PM 18128 (0x46D0)
CExtProviderClassObject :: DoExecuteMethod AddMembershipRule SMS Provider date 2:57:12 PM 18128 (0x46D0)
* ~ * ~ E: \ cm1610_rtm \ sms \ siteserver \ sdk_provider \ smsprov \ sspcollection.cpp (945): Unable to update collection. Insufficent rights. ~ * ~ * SMS Provider date 2:57:14 PM 18128 (0x46D0)
* ~ * ~ Unable to update collection. Insufficent rights. ~ * ~ * SMS Provider date 2:57:14 PM 18128 (0x46D0)
This can be generated even when the user has permissions on the two collections involved, source and destination.
Why this situation?
As you can see documented at https://social.technet.microsoft.com/Forums/en-US/5dae90b9-c44a-4257-b8f3-0e6e7dd93405/unable-to-update-collection-insufficent-rights?forum=configmanagergeneral, Apart from premissions on these two collections, the user must have permissions in the limiting collection of the destination collection.
Since it seems that the object is temporarily hosted in this repository, generating this access denied in the logs.
This can be managed from the console in Administration/Overview/Security/administrative users, and within the properties of the user, by selecting Security Scopes, we add in the desired security role the limiting collection explicitly.
I hope this helps you.
Hola de Nuevo.
Existen dos métodos de WMI en el smsprovider para gestionar los miembros de una colección (accesibles mediante un script o powershell):
AddMembershipRule
DeleteMembershipRule
Estos se suelen añadir en scripts para automatizar la inclusión de máquinas en colecciones, generalmente durante la instalación del sistema operativo en la ejecución de la task sequence.
Pero cuando tenemos un entorno securizado en ConfigMgr nos podemos encontrar con eventos como los siguientes al ejecutarlo, visibles en el smsprovider, que controla el acceso a los objetos en la base de datos:
ExecMethodAsync : SMS_Collection.CollectionID=”SIT00001″::AddMembershipRule SMS Provider date 2:57:12 PM 18128 (0x46D0)
Requested class =SMS_Collection SMS Provider date 2:57:12 PM 18128 (0x46D0)
Requested num keys =1 SMS Provider date 2:57:12 PM 18128 (0x46D0)
CExtProviderClassObject::DoExecuteMethod AddMembershipRule SMS Provider date 2:57:12 PM 18128 (0x46D0)
*~*~e:\cm1610_rtm\sms\siteserver\sdk_provider\smsprov\sspcollection.cpp(945) : Unable to update collection. Insufficent rights.~*~* SMS Provider date 2:57:14 PM 18128 (0x46D0)
*~*~Unable to update collection. Insufficent rights. ~*~* SMS Provider date 2:57:14 PM 18128 (0x46D0)
Esto se puede generar incluso cuando el usuario empleado tiene permisos sobre las dos colecciones implicadas, origen y destino.
¿A qué se debe esta situación?
Como se puede ver documentado en https://social.technet.microsoft.com/Forums/en-US/5dae90b9-c44a-4257-b8f3-0e6e7dd93405/unable-to-update-collection-insufficent-rights?forum=configmanagergeneral, aparte de en estas dos colecciones, el usuario debe tener permisos en la limiting collection de la colección de destino.
Ya que parece que de forma temporal se alberga en este repositorio el objeto, generando este acceso denegado en los logs.
Esto se puede gestionar desde la consola en Administration/Overview/Security/administrative users, y dentro de las propiedades del usuario, seleccionando Security Scopes, añadimos en el security role deseado la limiting collection de forma explícita.
Espero que esto os resulte de utilidad.
La semana pasada movimos una base de datos de un Site de SCCM a un nuevo servidor de SQL, esto tiene los ya conocidos efectos en ConfigMgr con la sincronización del sitio primario y el central, entrando en modo mantenimiento.
Esto es conocido y sobradamente documentado.
https://technet.microsoft.com/en-us/library/gg712697.aspx#BKMK_SiteDBRecoveryScenarios
Pero, ¿que pasa cuando se mueve la base de datos SUSDB si está en la instancia del sitio?
Esto no está tan documentado, solo localicé cómo realizarlo …
https://blogs.technet.microsoft.com/mwiles/2011/06/17/how-to-move-the-wsus-database/
En mi caso me encontré con algunas sorpresas:
En mi caso no fue bastante con el cambio de registro y nos complico bastante la migración ya que en ConfigMgr parece que esta todo bien menos un error conectando con la base de datos(Curiosamente con un UDL conectaba con la base de datos, pero WSUS no era capaz) y el registro estaba correctamente configurado, pero no conectó correctamente hasta que no se ejecutó el comando, esto no fue necesario en todos los servidores, solo en uno de ellos con politicas de seguridad muy restrictivas, pero creo que es bueno conocerlo.
This is where wsusutil.exe will come into play. This executable is located at C:\Program Files\Update Services\Tools. Besides the usual parameters that you can use with this utility, there is another set of parameters that become available when you use the PostInstall argument.
.\wsusutil.exe postinstall /? Da información sobre las opciones disponibles.
El error generado es:
System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)~~ at Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)~~ at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetConfiguration()~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServerConfiguration.Load()~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateWellKnownType(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateInstance(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetConfiguration()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.SetProxySettings(Boolean UseProxy, String ProxyName, Int32 ProxyServerPort, Boolean AnonymousProxyAccess, String ProxyUserName, String ProxyUserDomain, String ProxyUserPassword, Boolean AllowProxyCredentialsOverNonSsl)~~ClientConnectionId:00000000-0000-0000-0000-000000000000 SMS_WSUS_CONTROL_MANAGER AM 7928 (0x1EF8)
Failed to set WSUS Local Configuration. Will retry configuration in 1 minutes SMS_WSUS_CONTROL_MANAGER AM 7928 (0x1EF8)
3. Tras el cambio de servidor se generó una resincronización completa de WSUS, y esto no solo incluye todos los updates e información albergada en la base de datos, tambien registra de nuevo todos los clientes de WSUS, en un entorno pequeño esto casi no tiene consecuencias, pero un entorno grande como el nuestro (varios miles de clientes por site) esto afecta gravemente al rendimiento del servidor.
Como primer efecto el WSUSPool se cae, pero añadimos a esto que, si se tiene la configuración por defecto en IIS, tambien se producen caida del sistema operativo, afectando a ConfigMgr.
Cómo comentaba no localicé casi información, por lo que comparto con vosotros el plan de acción implementado.
Por favor cada entorno es diferente, pensad y si es posible testead estos cambios antes de implementarlos en produccion:
Esto da barra libre a IIS para emplear memoria y CPU, como tiene una avalancha de peticiones de clientes y los intenta atender a todos a la vez, la CPU se va al 100%.
Teneis una explicación detallada de este setting en https://www.iis.net/configreference/system.applicationhost/applicationpools/add/failure
2. Tambien en este caso es recomendable modificar el Private Memory Limit, este valor depende de cada servidor y la memoria instalada, por lo que no puedo dar recomendaciones.
Espero que esto resulte de utilidad a otros que se enfrenten a este tipo de migraciones.
Debido a este problema tuve que profundizar mucho en WSUS, estoy preparando una serie de post para explicarlo en profundidad, de forma que si alguien quiere dejar de trabajar en reactivo con WSUS, y realmente entender como funciona (la información disponible siempre me ha parecido confusa), pueda planificarlo como enfrentar este casi olvidado servicio.
Hasta ahora como veís solo doy explicaciones y soluciones a problemas encontrados y como se integra con SCCM, pero no el servicio en exclusiva, creo que falta información al respecto.
Hace unos meses localizamos un problema de configuración en nuestro entorno de producción donde tenemos configurados Software Update Points adicionales al primario para repartir la carga de los clientes y no sobrecargar al primario.
Los clientes no eran capaces de descargar las licencias de los updates (EULAs) desde el SUP asignado, mostrando estos errores en WindowsUpdate.log
Agent WARNING: Fail to download eula filehttp://SoftwareUpdatePointServer:8530/Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt with error 0x80244019
Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194
Esto provocaba que todos los clientes se volvieran al primario buscando esas licencias, lo que causo problemas de rendimiento en IIS.
Microsoft nos dio una respuesta al por que de este comportamiento, resumiendo las licencias de Software Updates son guardadas en la carpeta :\WSUS\wsuscontent unicamente en el primer SUP del site (Primario).
El directorio virtual de IIS para el contenido debe apuntar a esta carpeta, con lo que clientes sean habilitados para descargar los ficheros cuando los necesitan.
Como el resto de SUPs del site no tienen acceso a estos ficheros, se precisa redirigir la carpeta virtual de su IIS a la carpeta content del primario, estableciendo los permisos necesarios para que estos tengan acceso.
En el log de IIS veremos muchos eventos como este:
HEAD /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140140 8530 – 1.2.1.2 Windows-Update-Agent/7.9.9600.17415+Client-Protocol/1.21 – 404 0 2 0
, 01:40:35 1.1.1.1 GET /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140140 8530 – 195.245.107.27 Windows-Update-Agent/7.9.9600.17415+Client-Protocol/1.21 – 404 0 2 15 002112
, 01:41:19 1.1.1.1 HEAD /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/32/CD2727B5D17712BB5E29484A23273FC014567032.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 15
, 01:41:19 1.1.1.1 GET /Content/32/CD2727B5D17712BB5E29484A23273FC014567032.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/78/FAEB024981E30D4CB4A721C539F58D52FF241178.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/78/FAEB024981E30D4CB4A721C539F58D52FF241178.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 64 0
, 01:41:19 1.1.1.1 HEAD /Content/2D/79F8733BD22DFAD4571676F0C658EABDFADD162D.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/2D/79F8733BD22DFAD4571676F0C658EABDFADD162D.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/FB/412065D3BD90270B70B74EC4ACCB5F5BFCE17CFB.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/FB/412065D3BD90270B70B74EC4ACCB5F5BFCE17CFB.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 15
, 01:41:19 1.1.1.1 HEAD /Content/70/D84130F8BDB8EF51B34D25A1AAF452480C7CF770.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/70/D84130F8BDB8EF51B34D25A1AAF452480C7CF770.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 64 0
Otra posible causa para estos eventos precisa realizar en el primer SUP de la jerarquia lanzar un WSUS reset para descargar los ficheros de ELUAL que estan ausentes en el Content del primario.
Esta documentado en:
https://blogs.technet.microsoft.com/sus/2008/08/26/missing-end-user-license-agreement-eula-will-cause-error-0x80240033-in-the-updateshandler-log/
Cause: This can occur if the End User License Agreement (EULA) is missing from the WSUS Webcontent folder. By default
this will be installed to C:WSUSWSUSContent.
Resolution: In order to force WSUS to download missing EULAs, run the following from the command prompt:
wsusutil reset
This will force WSUS to check its database and metadata for missing EULAs and if they are missing it will download them from Microsoft Update. Complete a manual sync from within the Configuration Manager Admin and after this, the deployment package should appear and be ready to be installed
Espero que este os resulte de utilidad.
A few months ago a misconfiguration was found in my production environment where the additional MP/SUP/DP servers that add redundancy to the main Primary Site servers.
Clients were not able to download Software Update license files (EULA) from the MP/SUP/DP server, showing this error in the WindowsUpdate.log:
Agent WARNING: Fail to download eula filehttp://SoftwareUpdatePointServer:8530/Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt with error 0x80244019
Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190194
Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190194
This was making the clients fall back to the Primary Site for content, overloading the server with request and affecting the IIS performance on the machine, even hanging the OS.
Microsoft provided an explanation and a solution for this situation.
Summarizing… the SW Updates license files are stored in :\WSUS\wsuscontent folder only in the 1st Software Update Point (Primary Site).
The IIS virtual directory Content points to this location so clients can download content as they need.
Any additional SUP in the same Site won’t have the SW Update license files downloaded to this folder, hence the need to re-direct the IIs virtual folder to the Primary Site wsuscontent folder, that needs to be shared and permissions set accordingly.
On the IIS logs we can find lots of: HEAD /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140140 8530 – 1.2.1.2 Windows-Update-Agent/7.9.9600.17415+Client-Protocol/1.21 – 404 0 2 0
, 01:40:35 1.1.1.1 GET /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140140 8530 – 195.245.107.27 Windows-Update-Agent/7.9.9600.17415+Client-Protocol/1.21 – 404 0 2 15 002112
, 01:41:19 1.1.1.1 HEAD /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/AE/C3248EB572CB5F82E63CE9C6D73CFBF39B1052AE.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/32/CD2727B5D17712BB5E29484A23273FC014567032.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 15
, 01:41:19 1.1.1.1 GET /Content/32/CD2727B5D17712BB5E29484A23273FC014567032.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/78/FAEB024981E30D4CB4A721C539F58D52FF241178.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/78/FAEB024981E30D4CB4A721C539F58D52FF241178.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 64 0
, 01:41:19 1.1.1.1 HEAD /Content/2D/79F8733BD22DFAD4571676F0C658EABDFADD162D.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/2D/79F8733BD22DFAD4571676F0C658EABDFADD162D.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 HEAD /Content/FB/412065D3BD90270B70B74EC4ACCB5F5BFCE17CFB.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/FB/412065D3BD90270B70B74EC4ACCB5F5BFCE17CFB.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 15
, 01:41:19 1.1.1.1 HEAD /Content/70/D84130F8BDB8EF51B34D25A1AAF452480C7CF770.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 2 0
, 01:41:19 1.1.1.1 GET /Content/70/D84130F8BDB8EF51B34D25A1AAF452480C7CF770.txt 1603140141 8530 – 192.168.1.23 Windows-Update-Agent – 404 0 64 0
Other documented solution which may have the same symptoms is to force a sync on the top Software Update Point on the hierarchy an Wsus Reset so the EULA files are downloaded, this is documented at:
Cause: This can occur if the End User License Agreement (EULA) is missing from the WSUS Webcontent folder. By default
this will be installed to C:WSUSWSUSContent.
Resolution: In order to force WSUS to download missing EULAs, run the following from the command prompt:
wsusutil reset
This will force WSUS to check its database and metadata for missing EULAs and if they are missing it will download them from Microsoft Update. Complete a manual sync from within the Configuration Manager Admin and after this, the deployment package should appear and be ready to be installed
I hope that this be informative for you.
Hay situaciones en las que un servidor secundario parece perder comunicación con uno de usos puntos de distribución de forma aleatoria.
Aunque se mantenga la conectividad con ping, a tengamos acceso a la unidad Admin$ con la cuenta local de sistema, en el log distmgr.log vemos constantes eventos como los siguientes solo con uno de los DPs.
Failed to make a network connection to \\Server\ADMIN$ (0x35).
Cannot establish connection to [“Display=\\Server\”]MSWNET:[“SMS_SITE=S01”]\\Server\. Error = 53
Copying D:\Foler\File to \\SERVER02\SMSPKGD$\FileFolder, Failed, Win32 Error = 64 SMS_DISTRIBUTION_MANAGER date 7:53:25 AM 74756 (0x12404)
En mi entorno esto pasa con bastante frecuencia, y los pasos de diagnóstico y solución son siempre los mismos, por eso he creado un script con la solución de forma que se puede automatizar.
Por favor testeadlo antes de usarlo de forma extensiva, viene sin garantías y a mí me funciona, pero como reinicia el servicio smsexec puede tener impacto en producción.
Añadí algunos controles al script para que, ante las acciones con más impacto, pregunte antes de realizarlas, si se elimina esta parte, y se integra con una herramienta de monitorización, puede hacer tu vida como administrado de CofigMgr mucho más llevadera.
Aquí están las líneas, sòlo copia y pega en PowerShell (o el ISE) y a disfrutarlo:
#Script to repair the DPs connection events 53 and 64 on secondary site
#On ConfigMgr
#Created on 20 Oct 2016
#Created By Raul del Moral
#**************************************
# Version 2.0 adding the next features:
# Enable control on the script execution so ask for the restart on SmsExec service
# Enable logging on the server with the whole process
# Enable control on SmsExec service so if not detected stops
#**************************************
#Set the variables to use on the script
$DPName = Read-Host -Prompt ‘Enter the DP name’
if (!$DPName ) {Write-host -ForegroundColor Red -backgroundColor White “Please provide a DP name”
exit(1)}
$Admin = “$DPName\admin$”
$service = “SMS_EXECUTIVE”
#$Userlog = “$env:USERPROFILE\Desktop\DP_Repair.log” #If wants to have the logs on the Desktop session of server where the script is run
#$ServerLog= “\server\Unit$\path” #If wants to have the logs on the server where the script is run
$log = “C:\temp\testlog.txt” #To save the logs on the temp folder of the server where the script is run
$LogTime = Get-Date -Format “dd-MM-yyyy_hh:mm:ss”
$PatToCMTRACE = “C:\sccm\tools\CMTrace.exe” #Adapt to your server
$PathToDistmgr = “c:\SCCM\Logs\distmgr.log” #Adapt to your server
#Create the function to managed the input on the script
#Create Function for logging
Start-Transcript $Log -Append -NoClobber
Write-Host “###################################”
Write-Host “###################################”
Write-Host “$LogTime $env:computername $env:USERNAME”
Write-Host “###################################”
Write-Host “###################################”
#Create the function for ping confirmation on the remote DP
Function Ping_test (){
if(!(Test-Connection -Cn $DPName -BufferSize 16 -Count 1 -ea 0 -quiet))
{Write-Host “Cannot connect with server $DPName” -ForegroundColor Red -BackgroundColor white | Out-Default
Write-Host “$LogTime $env:computername $env:USERNAME” | Out-Default
}
Else {}#End If
}
#Create function to test Admin$
Function Test_Share (){
if(!(Test-Path \\$Admin -ea 0))
{Write-Host “Cannot connect with server share $Admin” -ForegroundColor Red -BackgroundColor white | Out-Default
Write-Host “$LogTime $env:computername $env:USERNAME” | Out-Default}
Else {}#End If
}
#Create function to stop the smsexec service
Function Stop_smsexec(){
Write-Host “Now will restart the service smsexe on server $env:computername” -ForegroundColor Yellow | Out-Default
Write-Host $LogTime | Out-Default
if((Get-Service $service -ErrorAction SilentlyContinue))
{(Stop-Service $service -Confirm -ErrorAction SilentlyContinue) #this will promt a confirmation before restart the service
}
Else {Write-Host “The machine $env:computername has no smsexec service running”
Write-Host “$LogTime $env:computername $env:USERNAME”
Exit 1
}#End If
}
#Timer for service stop, will wait to run the start command till the service is confirmed as stopped
Function Timer()
{
do { Start-Sleep -Milliseconds 200}
until ((get-service $service).status -eq ‘Stopped’)
}
#Create function to start the smsexec service
Function Start_smsexec(){
if(!(Start-Service $service -ea 0))
{Write-Host “SmsExec service started” -ForegroundColor Green -BackgroundColor white | Out-Default}
Write-Host “$LogTime $env:computername $env:USERNAME’r” | Out-Default
Else {
Write-Host “The SmsExec Service could not be started, will need to restart the machine” -ForegroundColor Red -BackgroundColor white | Out-Default
Write-Host “$LogTime $env:computername $env:USERNAME” | Out-Default
}#End If
}
#Execution of functions
Ping_test
Test_Share
Stop_smsexec
Timer
Start_smsexec
#Open the cmtrace to review the DP connection path to CMTrace tool and Path to the log to open
& “”$PathtoCMTRACE” ‘$PathToDistmgr'”
Stop-Transcript #Stop the logging
Enjoy it 🙂
configmgryyo 