none
Add-CMSoftwareUpdatePoint -UseProxy $true -UseProxyForAutoDeploymentRule $true -> results in: "WSUS Control Manager failed to configure proxy settings on WSUS Server" RRS feed

  • Question

  • When using the -UseProxy and -UseProxyForAutoDeploymentRule with value $true, the following logs indicate an error:

    SMS_WSUS_CONTROL_MANAGER: WSUS Control Manager failed to configure proxy settings on WSUS Server

    WSUSCtrl.log: Microsoft.UpdateServices.Administration.WsusInvalidDataException: The address of the proxy server cannot be empty.~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServerConfiguration.Validate()~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServerConfiguration.Save(Boolean detectConfigChange)~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.SetProxySettings(Boolean UseProxy, String ProxyName, Int32 ProxyServerPort, Boolean AnonymousProxyAccess, String ProxyUserName, String ProxyUserDomain, String ProxyUserPassword, Boolean AllowProxyCredentialsOverNonSsl)

    If the wizard is used, proxy information is already filled from Site system properties and the issue is not present.

    Did I miss something or is the cmdlet actually broken?

    kind regards,
    Tobias

    Thursday, April 18, 2019 7:26 PM

Answers

  • Hi Raj

    Thank you for the suggestion to audit the registry key.

    I did and according to the logs, it turned out that sitecomp.exe was responsible for change the values back.

    ------------------

    Object:
    Object Name: \REGISTRY\MACHINE\SOFTWARE\Microsoft\SMS\WSUS
    Object Value Name: ProxyServerPort
    Handle ID: 0x480
    Operation Type: Existing registry value modified

    Process Information:
    Process ID: 0x8e8
    Process Name: D:\SYSTEM\Microsoft Configuration Manager\bin\X64\sitecomp.exe

    Change Information:
    Old Value Type: REG_DWORD
    Old Value: 8080
    New Value Type: REG_DWORD
    New Value: 80

    ----------------------------------

    I dug a little deeper and found out that the proxy information for the SUP Role was not stored in the site control file.

    Query: Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = 'ZRH'" -Namespace root/SMS/Site_ZRH

    I came up with the following script as a workaround to the issue. It is used after the installation of the SUP via Add-CMSoftwareUpdatePoint.

    --------------------------------------------------

    function Set-CMSUPProxyInformation {
        Param(
            [Parameter(Mandatory=$true)]$proxyname,
            [Parameter(Mandatory=$true)]$proxyserverport
        )
        ### Information about site control file found @ http://www.chegorian.id.au/?p=38 ###

        #get site servers sitecode
        $smssitecode = (Get-WmiObject -Namespace "root\SMS" -Class "SMS_ProviderLocation" -Filter "ProviderForLocalSite='True'" -ErrorAction Stop).SiteCode
        
        # Get a session handle for the site control file
        $scf = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name GetSessionHandle
        # Refresh the WMI copy of the site control file
        $refresh = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name RefreshSCF -ArgumentList $smssitecode
            
        $SCIComponentSet = Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = '$($smssitecode)'" -Namespace "root/SMS/Site_$($smssitecode)"
        foreach ($SCIComponent in $SCIComponentSet){
            $props = $SCIComponent.Props;
            foreach ($prop in $props){
                if ($prop.PropertyName -eq "ProxyName"){
                    $prop.Value2 = $proxyname
                }
                if ($prop.PropertyName -eq "ProxyServerPort"){
                    $prop.Value = $proxyserverport
                }
            }
            $SCIComponent.Props = $props;
            $SCIComponent.Put()
        }
        # Commit site control file from WMI to the actual file
        $commit = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name CommitSCF -ArgumentList $smssitecode
        # Release session handle
        $scf = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name ReleaseSessionHandle -ArgumentList $scf.SessionHandle
    }

    -----------------------------------

    Still I'm wondering why the Add-CMSoftwareUpdatePoint cmdlet does not set the information correctly.

    Any thoughts?

    Best regards,

    Tobias

    Friday, April 19, 2019 8:33 PM

All replies

  • The following Registry Values are not set by Add-CMSoftwareUpdatePoint:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\WSUS\ProxyName

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\WSUS\ProxyPort

    Setting these Values after installing the SUP Role via Powershell, fixes the issue.

    Still it seems that the Cmdlet should be able to set these values correctly.


    Thursday, April 18, 2019 8:04 PM
  • Hello,
     
    Glad to hear that you have already fixed it.
     
    Based on the error message, the issue should be caused by the empty proxy server address. We should know that before we set the SUP to use proxy we should add it in the site system properties first. Sorry, from your description I am not clear if you have set it before or set it when installing the SUP.
     
    However, in the PowerShell we could check if we set it via command
     
    (get-cmsitesystemserver -sitecode "cs1" -sitesystemserver "svrcm01.css.int").props
      
    If the proxy is not set correctly, we could set it via command Set-CMSiteSystemServer. And it would create the registry values you mentioned.
     
    And when you set proxy by command Add-CMSoftwareUpdatePoint or Set-CMSoftwareUpdatePoint, they won't set the registry values. Then only modify the "UseProxy" value under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\WSUS".
     
    Hope above information could help you and look forward to your feedback.
     
    Best Regards,
    Ray
     

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 19, 2019 5:36 AM
  • Hi Raj

    Thank you for your response.

    I thought I fixed it by adding the registry values manually. Unfortunately it only fixed it for a short time. Another process seems to erase these values after a while and I'm back at square one.

    I did not mention that I set the proxy values explicitly via Set-CMSiteSystemServer. I did mention that if I'm using the GUI wizard to set up the SUP, the Proxy Values are already prefilled from the Site System properties, so I assumed these values are corectly set already.

    I did a check with Get-CMSiteSystemServer regardless and this is the output:

    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyName
    Value                 : 0
    Value1                : 
    Value2                : 192.168.245.198

    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyServerPort
    Value                 : 8080
    Value1                : 
    Value2                : 

    What strikes me as odd is the fact that the correct proxy value is set in Value2 instead of Value.

    Another point that is maybe worth mentioning: The Proxy information is provided trough the config file that is used in the unattended installation of SCCM.

    Any thoughts on that?

    Best regards,

    Tobias

    Friday, April 19, 2019 7:33 AM
  • Hello Tobias,
     
    Don't need to worry about the Value position because it's also in Value2 in my environment.
     
    I have tested these commands in my environment and I find that when we set WSUS to use proxy, it would directly read the registry values mentioned above. So even if the values are displayed correctly in the console or via  Get-CMSiteSystemServer, the operation to enable proxy would be failed if the registry values are not exist or incorrect.
     
    As you said, another process seems to erase these values, so we need to find out which process is the culprit. Here is a method to monitor any change to the value via audit.
     
    1> Run the following command in a elevated CMD to enable registry audit.
     
    auditpol /set /subcategory:"registry" /success:enable /failure:enable
     
    2> Right-click the registry key "WSUS" and select Permissions. Click Advanced, then click Auditing.
     
    3> Click Add, select everyone as principal, select "This key an subkeys" as Applies to, then select Full Control Permissions.
     

      
    4> Then we could check the audit records in Event Viewer > Windows Logs > Security. Use Event ID as filter to see all value modified records.
     

     
    Hope above information could help you and look forward to your feedback.
     
    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 19, 2019 9:35 AM
  • Hi Raj

    Thank you for the suggestion to audit the registry key.

    I did and according to the logs, it turned out that sitecomp.exe was responsible for change the values back.

    ------------------

    Object:
    Object Name: \REGISTRY\MACHINE\SOFTWARE\Microsoft\SMS\WSUS
    Object Value Name: ProxyServerPort
    Handle ID: 0x480
    Operation Type: Existing registry value modified

    Process Information:
    Process ID: 0x8e8
    Process Name: D:\SYSTEM\Microsoft Configuration Manager\bin\X64\sitecomp.exe

    Change Information:
    Old Value Type: REG_DWORD
    Old Value: 8080
    New Value Type: REG_DWORD
    New Value: 80

    ----------------------------------

    I dug a little deeper and found out that the proxy information for the SUP Role was not stored in the site control file.

    Query: Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = 'ZRH'" -Namespace root/SMS/Site_ZRH

    I came up with the following script as a workaround to the issue. It is used after the installation of the SUP via Add-CMSoftwareUpdatePoint.

    --------------------------------------------------

    function Set-CMSUPProxyInformation {
        Param(
            [Parameter(Mandatory=$true)]$proxyname,
            [Parameter(Mandatory=$true)]$proxyserverport
        )
        ### Information about site control file found @ http://www.chegorian.id.au/?p=38 ###

        #get site servers sitecode
        $smssitecode = (Get-WmiObject -Namespace "root\SMS" -Class "SMS_ProviderLocation" -Filter "ProviderForLocalSite='True'" -ErrorAction Stop).SiteCode
        
        # Get a session handle for the site control file
        $scf = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name GetSessionHandle
        # Refresh the WMI copy of the site control file
        $refresh = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name RefreshSCF -ArgumentList $smssitecode
            
        $SCIComponentSet = Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = '$($smssitecode)'" -Namespace "root/SMS/Site_$($smssitecode)"
        foreach ($SCIComponent in $SCIComponentSet){
            $props = $SCIComponent.Props;
            foreach ($prop in $props){
                if ($prop.PropertyName -eq "ProxyName"){
                    $prop.Value2 = $proxyname
                }
                if ($prop.PropertyName -eq "ProxyServerPort"){
                    $prop.Value = $proxyserverport
                }
            }
            $SCIComponent.Props = $props;
            $SCIComponent.Put()
        }
        # Commit site control file from WMI to the actual file
        $commit = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name CommitSCF -ArgumentList $smssitecode
        # Release session handle
        $scf = Invoke-WmiMethod -Namespace "root/SMS/Site_$($smssitecode)" -Class SMS_SiteControlFile -Name ReleaseSessionHandle -ArgumentList $scf.SessionHandle
    }

    -----------------------------------

    Still I'm wondering why the Add-CMSoftwareUpdatePoint cmdlet does not set the information correctly.

    Any thoughts?

    Best regards,

    Tobias

    Friday, April 19, 2019 8:33 PM
  • Hello Tobias,
     
    I have tested again in my lab. The proxy name and port under class SMS_SCI_SysResUse.props where the role is SUP or Site System is set when setting Site system properties. In other words, when we set proxy for SUP, the name and port should already be in there, all we need to do is just enable it.
     
    So Add-CMSoftwareUpdatePoint cmdlet should not set them because they are set when you set the Site System properties. 
     
    If you said that you can't get them via the query, I still suspect that you have not set up the Site System properties correctly.
     
    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, April 23, 2019 11:10 AM
  • Hi Raj

    After your feedback I figured I'd retry the whole process for documentation purposes. 

    I took another fresh installed SCCM Environment that was setup exactly like the other one.

    Checking the Environment

    Before I started the SUP Component install, I checked the proxy Settings of SMS Site System in two different ways:

    PS ZRH:\> ($SCIComponentSet = Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Site System' AND SiteCode = 'ZRH'" -Namespace "root/SMS/Site_ZRH").props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }
    
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyName
    Value            : 0
    Value1           : 
    Value2           : 192.168.245.198
    PSComputerName   : 
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyServerPort
    Value            : 8080
    Value1           : 
    Value2           : 
    PSComputerName   : 
    PS ZRH:\> (Get-CMSiteSystemServer -SiteCode ZRH).props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }
    
    
    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyName
    Value                 : 0
    Value1                : 
    Value2                : 192.168.245.198
    
    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyServerPort
    Value                 : 8080
    Value1                : 
    Value2                : 


    The query for SUP Proxy information in SMS_SCI_SysResUse did no yield any results, which is fine when SUP Component is not installed yet:

    (Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = 'ZRH'" -Namespace "root/SMS/Site_ZRH").props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }

    --------------------------------

    SUP Component Installation

    Now I invoked the SUP Component Install by issueing the following command:

    Add-CMSoftwareUpdatePoint -SiteCode "ZRH" -SiteSystemServerName "server.domain.intern" -UseProxy $true -UseProxyForAutoDeploymentRule $true -WsusIisPort 8530 -WsusIisSslPort 8531

    The Error Message in SMS_WSUS_CONTROL_MANAGER immediately showed up:

    WSUS Control Manager failed to configure proxy settings on WSUS Server "server.domain.intern".

    ---------------------------

    Checking the Environment after SUP Component Install

    Now I checked the SMS Site System Settings again:

    PS ZRH:\> ($SCIComponentSet = Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Site System' AND SiteCode = 'ZRH'" -Namespace "root/SMS/Site_ZRH").props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }
    
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyName
    Value            : 0
    Value1           : 
    Value2           : 192.168.245.198
    PSComputerName   : 
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyServerPort
    Value            : 8080
    Value1           : 
    Value2           : 
    PSComputerName   : 
    PS ZRH:\> (Get-CMSiteSystemServer -SiteCode ZRH).props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }
    
    
    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyName
    Value                 : 0
    Value1                : 
    Value2                : 192.168.245.198
    
    SmsProviderObjectPath : SMS_EmbeddedProperty
    ItemType              : 
    PropertyName          : ProxyServerPort
    Value                 : 8080
    Value1                : 
    Value2                : 

    This time the Query for the SUP Proxy Information returned the following:

    PS ZRH:\> (Get-WmiObject -Query "Select * from SMS_SCI_SysResUse WHERE RoleName = 'SMS Software Update Point' AND SiteCode = 'ZRH'" -Namespace "root/SMS/Site_ZRH").props | Where-Object { $_.PropertyName -eq "ProxyName" -or $_.PropertyName -eq "ProxyServerPort" }
    
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyName
    Value            : 0
    Value1           : 
    Value2           : 
    PSComputerName   : 
    
    __GENUS          : 2
    __CLASS          : SMS_EmbeddedProperty
    __SUPERCLASS     : 
    __DYNASTY        : SMS_EmbeddedProperty
    __RELPATH        : 
    __PROPERTY_COUNT : 5
    __DERIVATION     : {}
    __SERVER         : 
    __NAMESPACE      : 
    __PATH           : 
    ItemType         : 
    PropertyName     : ProxyServerPort
    Value            : 80
    Value1           : 
    Value2           : 
    PSComputerName   : 

    As suspected, the Proxy Information for the SUP Component is not configured.

    Summary

    The Site System Server Configuration reports that a proxy information is set for the Site System.

    Installing the SUP Component with Add-CMSoftwareUpdatePoint Cmdlet did not set the Proxy Information for SUP Component.

    Variation 1 of the Installation Procedure

    I did a reset on the installation and varied the installation process by setting the proxy for the Site System again with:

    Set-CMSiteSystemServer -ProxyServerName "192.168.245.198" -ProxyServerPort "8080" -SiteSystemServerName "server.domain.intern" -SiteCode ZRH

    I then installed the SUP Component again with the PowerShell Cmdlet. 

    The result was the same.

    Variation 2 of the Installation Procedure

    I did another reset of the system.

    I then installed the SUP Component via the GUI Wizard, which filled the proxy information in the wizard automatically from the Site System Configuration.

    This time the proxy information for the SUP Component in Site Control File was set correctly.

    Conclusion

    I won't abandon the possibility that some information about the proxy in the site system is not configured correctly, but as of now I do not know what that could possibly be.

    That lets me suspect that the Cmdlet is not working properly.

    Question

    Can you reproduce the issue in your lab by doing the installation and the checks the same way?

    It would be helpful to know if something in my standardized SCCM Base setup is causing this, or if it is the same in your environment.

    I'm looking forward to your feedback.

    Best regards,

    Tobias

    Thursday, April 25, 2019 10:07 AM