I have been trying to figure out why Wake On Lan works for Right Click Tools, but not for SCCM Scheduled Deployments.
In the wolmgr.log file I found this happening every five seconds: "Failed to get WOL inbox on AMT Proxy component. Wait 5 seconds... SMS_WAKEONLAN_MANAGER 9/19/2018 11:32:24 AM 480 (0x01E0)".
In the wolcmgr.log file I don't see any errors except this happening about four times a day, which I think is referring to the endless errors shown in the other log file: "CBaseCounter::Initialize - Registered performance counter "Total Number of Packets failed" SMS_WAKEONLAN_COMMUNICATION_MANAGER 9/19/2018 2:01:59 AM 9496 (0x2518)"
I have tried to look up these error messages and haven't found anything to help me get this resolved.
I have tried various ports, including the default (9) and 12287, currently it is on 7. We are being told to use subnet directed broadcasts by our network team due to some limitations with our Cisco network configuration.
I do have a SQL Server Agent (ADK) service that was disabled. I enabled it and it starts but turns off immediately. I don't know if that is related at all. I did have some deployment issues with Windows 7 drivers giving errors during the task sequence, even though they were installing. So I installed a Windows 8.1 ADK after seeing an article about bugs with the latest Win10 ADK and SCCM Task Sequences installing Win7 drivers. I've since then installed Win10 1703 ADK, which works on one of my other SCCM servers on Win7 deployments fine, and I was having this WOL problem before installing 1703 ADK.
Under Administration > System Status > Site Status > Management Point, when I show messages I see these:
*Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 12:47:56 PM SMS_WAKEONLAN_MANAGER
6500 3384
3988
Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 9:39:03 AM SMS_WAKEONLAN_MANAGER
6500 2924
2636*
ADK SQL Server Agent
SCCM WOL configuration
WOL ports
wolmgr.log file screen shot
RightClickTools WOL Configuration
Related
We are using on site Dev-Ops and have a similar problem to that described in the link Example from SO.
But ours is intermittent.
Our environment uses two build and deploy machines, which each deploy machine having two worker agents.
For one of our projects, when it is deployed, we constantly get the error:
The VisualStudioRemoteDeployerc4d3852f-411b-48ba-97d8-5e09c8d07ce4 service failed to start due to the following error:
%%2
But here is the rub, not every time. Sometimes the deployment completes without error.
Other projects that use the same deployment machine and the same target server work each and every time without fail.
The deployment log reports "The WSMan provider host process did not return a proper response." as an error.
Checking the allocated memory, described in PowerShell Out of Memory, to find our set at 2.1 Billion.
This is an interesting issue that I have uncovered. The source of this problem stems from the interaction of McAfee Endpoint security.
Said antivirus was reporting that when the remote powershell script, using WSMan, was called. McAfee, saw this as a viral payload and canceled the deployment by stopping the service from running and deleting the payload. This has been reported to McAfee as an issue. In the mean time, internal network security settings for McAfee has had to be modified to ignore the processes used by powershell in remote deployment.
We recently upgraded our Windows 10 test environment with ChromeDriver v87.0.4280.20 and Chrome v87.0.4280.66 (Official Build) (64-bit) and after the up-gradation even the minimal program is producing this ERROR log:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Minimum Code Block:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
Console Output:
DevTools listening on ws://127.0.0.1:64170/devtools/browser/2fb4bb93-79ab-4131-9e4a-3b65c08dbffb
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
[9848:10684:1201/013233.172:ERROR:device_event_log_impl.cc(211)] [01:32:33.173] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Anyone facing the same? Was there any change in ChromeDriver/Chrome v87 with respect to ChromeDriver/Chrome v86?
Any clues will be helpful.
However these log messages can be supressed from appearing on the console through an easy hack i.e. by adding an argument through add_experimental_option() as follows:
options.add_experimental_option('excludeSwitches', ['enable-logging'])
Code Block:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
# to supress the error messages/logs
options.add_experimental_option('excludeSwitches', ['enable-logging'])
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
My apologies for the log spam. If you aren't having issues connecting to a device with WebUSB you can ignore these warnings. They are triggered by Chrome attempting to read properties of USB devices that are currently suspended.
After going through quite a few discussions, documentations and Chromium issues here are the details related to the surfacing of the log message:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Details
It all started with the reporting of chromium issue Remove WebUSB's dependency on libusb on Windows as:
For Linux (probably Mac as well), both WebUSB notification and communication works correctly (after allowing user access to the device in udev rules).
For Windows, it seems that libusb only works with a non-standard WinUsb driver (https://github.com/libusb/libusb/issues/255).
When the hardware is inserted and the VID/PID is unknown to the system, windows 10 correctly loads it's CDC driver for the CDC part and the WinUSB driver (version 10) for the WebUSB part (no red flags). However, it seems that chrome never finds the device until I manually force an older WinUSB driver (version 6 - probably modified also) on the interface.
The solution was implemented in a step-wise manner as follows:
Start supporting some transfers in the new Windows USB backend
Fix bulk/interrupt transfers in the new Windows USB backend
[usb] Read BOS descriptors from the hub driver on Windows
[usb] Collect all composite devices paths during enumeration on Windows
[usb] Remove out parameters in UsbServiceWin helper functions
[usb] Support composite devices in the new Windows backend
[usb] Detect USB functions as Windows enumerates them
[usb] Support composite devices with multiple functions
[usb] Hold interface requests until Windows enumerates functions
[usb] Add direction parameter to ClearHalt
[usb] Count references to a WINUSB_INTERFACE_HANDLE
[usb] Implement blocking operations in the Windows backend
These changes ensured that the new backend was ready to be tested and was available through Chrome Canary and chrome-dev-channel which you can access manually through:
chrome://flags#enable-new-usb-backend
More change requests were submitted as follows:
[usb] Mark calls to SetupDiGetDeviceProperty as potentially blocking: According to hang reports this function performs an RPC call which may take some time to complete. Mark calls with a base::ScopedBlockingCall so that the thread pool knows this task may be busy for a while.
variations: Enable NewUsbBackend in field trial testing config: This flag was experimental as beta-channel uses this change configuration as the default for testing.
As the experimental launch of the new backend appeared to be stable, finally these configuration was enabled by default so that the chanege rolls out to all users of Chrome 87 through usb: Enable new Windows USB backend by default. Revision / Commit
The idea was once this configuration becomes the default for a few milestones, Chromium Team will start removing the Windows-specific code from the old back-end and remove the flag.
Road Ahead
Chromium Team have already merged the revision/commit to Extend new-usb-backend flag expiration within Chrome v90 which will be available soon.
Update
As per #ReillyGrant's [Committer, WebDriver for Google Chrome] comment :
..." it would be good to reduce the log level for these messages so they don't appear on the console by default but we haven't landed code to do that yet"...
References
You can find a couple of relevant detailed discussions in:
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Selenium on Windows OS
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Chrome through Selenium
I encounered this problem yesterday,and I has fixed it by update all available windows update.
https://support.microsoft.com/en-us/windows/what-to-try-if-your-touchscreen-doesn-t-work-f159b366-b3ef-99ad-24a4-31a4c62ab46d
A partial solution that worked for me
I was getting this error too. It was stopping my program running.
I unplugged all my USB devices, ran the program, with no error.
Plugged the devices back in, ran the program. I am still getting the error, however, the program finished without the error stopping the program.
Note: For WebdriverIO on Windows 10, this suppresses the error messages for me:
"goog:chromeOptions": { "excludeSwitches": ["enable-logging"] }
Yesterday our extracts failed to refresh with the following message (image extract_error):
Failure: Failed 1 time. Sign in failed.
Resolution Details: Check the Data Connection page for necessary updates to an access token or embedded credentials.
I verified that all our passwords were unchanged and test connections which were successful.
The tableau dashboards now give an error message saying:
HTTP 404:
Unable to connect to the server "localhost". Check that the server is running and that you have access privileges to the requested database. (image tableau_error)
Further, when I opened the Server Status page, I saw that our one of our two Vizql, backgrounder and data servers were down. We have two of each and only one of them is active for all three of them. (image server_status)
So, I decided to remote desktop into the server and run the tabadmin status -v command and strangely it is showing that all processes are running. (image tabadmin_status)
Finally, I opened a case with Tableau Customer Portal and letting them know about this issue (they asked me send them the log.zip file) but the mean time I was trying to problem solve this issue. Any help would be really appreciated.
After trying a lot of things, one process seemed to work.
Stopped the tableau server
Configured it to run 1 Vizql server process instead of 2
Started the server again
Finally, it worked. The status page now shows all the processes are active.
Hopefully, this helps someone who is facing a similar problem.
This may be caused by a firewall issue. Since tabadmin status -v returned all as "running" the cluster is healthy and this is a false alert. The firewall rules could be allowing just the first port and not the entire range (see https://onlinehelp.tableau.com/current/server/en-us/ports.htm) to respond to requests from the application server to build that fancy table with the green and red boxes.
The firewall can be reverted/altered behind the scenes for a number of reasons, usually windows updates or regular group policy synchronization.
Try disabling the windows firewall (https://www.faqforge.com/windows-server-2016/turn-off-firewall-windows-server-2016/), or add an inbound rule allowing access to all ports if your org policy doesn't allow you to actually turn it off. (Follow the steps here, except use "All Local Ports" instead of "Specific Local Ports" https://www.parallels.com/blogs/ras/configuring-windows-server-firewall-for-parallels-ras/)
I had a similar problem and followed these similar steps that Sravee mentioned above to bring the all processes back to active.
Stopped the server
Change the configuration for VizQL server from 2 to 1
Started the server
Enter the licence key (else the server status page will show unlicensed error)
Note: This does not bring the site back but this step is for 'tricking' VizQL server
Stopped the server again
Change the VizQL configuration from 1 to 2 now.
Start the server
Enter the license key
This steps did bring back the server back to active for us. Posting to see if this helps who faces the same problem. Thank you so much.
I provide support for a large application across multiple servers. System has been running live for 6+ months.
8th December: total system failure. iisreset across each of the servers sorted it out. Everything back to normal.
Post failure investigation showed various processes not able to get a response from a particular server which hosts an instance of Dynamics CRM (2011 R11). Specifically it seems the SOAP service was not responding (Organization.svc). 503 - Server Unavailable (really it was just the web service). I suspect it died.
Having the exact time of the error I checked the event logs on the server but these did not have anything of use. The last error prior to the failure was a report rendering error which was 9 minutes before the system actually went down. Surely if web service crashed this would be reflected in the event log?
Fast forward to today, 8th January and the system fails again. The 8th of the month again! iisreset fixes it... again!
Again, completely useless event logs showings no errors prior to failure.
Entertained the idea of Dynamics CRM trace logging but this is out of the question due to the performance hit.
Apart from the event logs where else to look? Are there possible external factors or causes? I'm trying to find the root cause but have run out of ideas!
While this may not address the source of your problem, maybe it can help minimize the symptoms. May I suggest that you configure the IIS server to recycle the application pool at a scheduled interval within your production environment.
http://technet.microsoft.com/en-us/library/cc753179%28v=ws.10%29.aspx
I'm trying to enable MSMQ on my development computer (running Windows 7).
I go to turn windows features on or off -> Microsoft Message Queue (MSMQ) Server Core -> Check MSMQ Active Directory Domain Services Integration AND MSMQ HTTP Support.
When I click OK, I get the error "An Error has occurred. Not all of the features were successfully changed." -> Click OK -> "You must restart your computer to apply these changes".
I've clicked Restart Now and Restart later and no matter what, same issue every time.
If I selected Restart later and go into Services...I see Message Queuing (stopped), and if I try to start the service, I get the error "Windows could not start the Message Queuing service on Local Computer. Error 0x80070005: Access denied."
I checked my privileges and I am an Admin on the machine. Just to be safe, I even logged into the machine as the actual Administrator. Same scenario.
Furthermore, when I go into the Event Viewer, I check the Application logs. I have an error with MSMQ as the Source. EventID: 2076, Error: The logger files cannot be initialized. The file QMLog in the Msmq\Storage folder is corrupted or absent. Error 0x80070005: Access denied.
If I check the System Logs, I see another error with the source being Service Control manager. Error eventId: 7023, Error: The Message Queuing service terminated with the following error: %%-2147024891
When I look up the error codes on Microsoft, there is NOTHING.
I had something like this - not sure how it came about as I always had AD integration turned ON for my MSMQ (as I needed it) but somewhere along the line, it got turned off and I couldn't turn it back on again via Control Panel - I would get the error behaviour (and restart!) that the OP describes. To fix it, I accessed my machine via the AD services manager app on one of our domain servers and deleted the "msmq" object that was under it.
I restarted my local MSMQ service on my machine AND rebooted (not sure which or both was required) and then when I checked my local registry entries, it indicated I was correctly running in AD mode once again. Everything started to work again after that.
This link was helpful in giving me the right direction to go in: Technet MSMQ delete stale objects article