While deploying patches to a group of computers, 3 out of 10 machines reports “Waiting for downloads to be mirrored.” This machines might be connected through VPN or wireless and reports to the same relay through which the other machines have received the required patches without issue.
The Server/Relay cache have several GBs free to accommodate any new content. What can be the possible reason here?
I have sent other actions to the client and received expected response, however the only issue is while deploying the patches.
It could be many reasons. I would start with seeing if you can download the payload from the original source location and then also check that the SHA matches. You could also
The BigFix Diagnostics Tool that comes installed with the BigFix Server will allow you to see the gather status and the download status of the BigFix Server.
To use the BigFix Diagnostics Tool to view the download and gather status:
On the BigFix Server computer go to Start > BigFix Enterprise > Enterprise Server > BigFix Diagnostics Tool
Click on the “Services” tab
Click either the “View Mirror Gather Server Status” or “View Mirror Download Status” and a web page will open with the appropriate status window
To see the gather status without using the BigFix Diagnostics Tool, open up your web browser and type the following url: http://(IP Address of Server):(Port Number)/cgi-bin/bfenterprise/besgathermirrornew.exe
To see the download status without using the BES Diagnostics Tool, open up your web browser and type the following url: http://(IP Address of Server):(Port Number)/cgi-bin/bfenterprise/besmirrorrequest.exe
The (IP Address or FQDN of Server) in the examples above is the IP address or the hostname of the BES Server or BES Relay specified in the masthead and the (Port Number) is the port number specified in the masthead (default is 52311).
I was able to download the payload from the relay.
The same Relay is being used during patching of other clients which went perfectly normal, it’s only with these three clients for which the download status never changes from “Waiting for downloads to be mirrored”.
These clients might be connected through VPN or wireless.
Blank actions and client restarts are acknowledged as expected.
We are trying to push these patches through a baseline.
Evaluating Windows 10 Enterprise Version 1703 Available - Windows 10 (x64) (English (United States))
Evaluating Windows 10 Multi-edition VL Version 1709 Available - Windows 10 (x64) (English (United States))
3062591: Security advisory: Local Administrator Password Solution (LAPS) now available - GPO CSE (x64)
Evaluating Windows 10 Enterprise Version 1703 Available - Windows 10 (x64) (English (United States))
Evaluating Windows 10 Multi-edition VL Version 1709 Available - Windows 10 (x64) (English (United States))
You aren’t pushing both of these to the same client right? These two are Windows 10 Upgrades - 1703 is the “Creators Update”, and 1709 is the “Fall Creators Update”. You shouldn’t deploy both on the same host, they’re exclusive and would conflict at reboot time.
If your intent is to go to version 1709, then skip the 1703 update altogether.
And their downloads are about 4.5 GB each, which could be overunning cache or disk sizes on the relays or clients.
So on the Windows 10 Available fixlets there are two possible answers.
Manual Caching is required or you need to have configured a manual repo.
begin prefetch block
add prefetch item name =en_windows_10_enterprise_n_version_1703_updated_july_2017_x64_dvd_10925779.iso sha1=b2cf8378183724cc65a5caa06f145a2612d458dd size=4553793536 _**url={value of setting "_BESClient_AllowCustomRepoDownloads" of client | "http://**MANUAL_BES_CACHING_REQUIRED**/"}**_en_windows_10_enterprise_n_version_1703_updated_july_2017_x64_dvd_10925779.iso sha256=94b426a094bdb0ce06d3dfe371b009eb95f883c5c14c4855424982613e6cbea1
end prefetch block
second possibility cache settings locally are not large enough.
This Fixlet requires downloading the Windows 10 ISO image before deploying the Fixlet. You can use a custom repository to do so. Once this Fixlet completes, restart the target to complete the upgrade process.
Before you deploy the Fixlet:
Ensure that there is sufficient hard disk space.
Check the .iso file size. If it is necessary, increase the pre-caching download limit of your endpoints.
Through the BigFix console, you can set the limit by adding the following settings: _BESClient_Download_PreCacheStageDiskLimitMB _BESClient_Download_NormalStageDiskLimitMB
For more information about configuration settings, see this wiki article.
You can choose to use a custom repository from which the Windows 10 ISO image can be downloaded. For more information, see this wiki article. Note:Ensure that the file name of the ISO image is the same in the custom repository and in the action script to avoid errors.
After applying the Fixlet, it might take some time for the restart and upgrade process to complete, depending on connection and machine capabilities.
The ISO needs to be downloaded and stored in your downloads directory from MSDN or your MS Licensing Portal.
-jgo
It’s interesting that a few weeks ago, out of the blue I noticed having this message quite wide spread for actions running in our environments. I chalked it up to an assumed change in antivirus real time scanning so I reluctantly added the bigfix client folder to AV exclusion rules but I’m not sure if it was a 100% fix.