I've just installed UDT 3.2 into my existing Orion system. I am running NPM 11.0.1, SAM 6.1.1, NTA 3.11. I have added my 10 Domain Controllers in UDT, but 3 of them come back with the following status, "Polling Failed, check security log access credentials" The domain controllers are 2008R2, 2012 and 2003. The account I am using is a member of the Domain Admins group. I've checked every permission I can think of on the logs, but the account has all needed permissions. I've been able to remotely access the logs with the account. I'm not sure what else to check as I can't find any other errors. When I tested UDT 3.1, I did not have this issue. I am using the same account as my test. Thanks for any pointers.
Check this KB. I followed this and i was able to poll succefully!!
If the AD is setup please run the compatibility checker against the DC.
UDT COMPATIBILITY CHECKER
Run UDTCompatibilityChecker.exe from here:
C:\Program Files (x86)\SolarWinds\Orion\UDT
1) Click New and enter any session name (eg, test), using “Orion Node” as the source. Enter login credentials for the web console (it uses SWIS)
2) Select the Node, and select the type of tests to complete against this node:
- WMI to test access to Domain controllers for User Logins
I would like to see a way to disable the banner alert for the DC's not polling. It is super annoying and it will pop up when a site is down for power failure or MPLS down or whatever. I would rather just not have a banner and have a standard alert.
I found my root cause for problem DCs. For some reason, the Windows firewall was not correctly configured on the two DCs failing at regular intervals. Corrected the policy to conform with our GPO settings, verified correct GPO was applied, and haven't had a failure since.
It looks like people are running into this problem for some different reasons however this did happen to me recently after upgrading to 3.2.0 so here is my story.
Basically all of the 10 DC's were showing polls failing, none of the hotfixes available made any change to this for me. When I went into my DC nodes and tested the credentials everything came back as good but in UDT they still continued to fail - even after removing them from Solarwinds and re-adding them. I decided to call support however during the 25 minutes I was waiting on hold to try and open a case I seemed to resolve the issue for now. I went into the settings -> UDT Settings -> View UDT Job Status. From in here I was able to track down my DC's and manually clicked the poll now button for each DC and they are all back up now and reading information properly. They have stayed up since but it has only been a couple days and the server hasn't been restarted since so I I'm still not sure if we are at risk of encountering this again.
This is the solution I referred to in my last post. It is not a permanent fix. The poll failures will return. It may be a day or a week, but eventually it does return (at least for me). So it seems that it's the scheduled poll that fails. The next time you get a polling failure, look at the AD Domain Controller Polling Details in the DC's Node Summary View. The next poll time will be in the past and will never increment until a new poll is successful (by forcing a manual poll).
Same here. We've running standalone UDT 3.2 and getting error Polling Failed, Check security log Access credentials" every 30 minutes.
When we test the credentials it seems ok.
I couldn't find any hotfix about UDT, could someone help me about it?
PS: Polling Engine version is SolarWinds Orion Core Services 2014.2.1"
I am finding that the DCs occasionally self recover to a working state, but it's pretty rare. Had to set the polling rates down to the minimums to really see it happen though (5m).
Based on a conversation with support.
Even though the issue is transient instead of being all the way broken (or not), we seem to have a pretty high probability of resolution with:
Looks like it was both problems to one degree or another. I'm used to missing packet filter rules killing things a lot more reliably than "every now and then" soo... I want to say it was more the Hotfix that got things stable, but I don't know. I haven't seen any DCs error out in the last four hours, which is a huge improvement for me (I have polling intervals set very low while testing).
Along with the Event Manager firewall rules being needed, which we ran into as well, we also found the events weren't being logged anymore on Win2k12r2. We had to enable the following in Group Policy.
This is a different experience than me. I usually have this issue once or twice per day on seemingly random DC's. If I don't do anything, it will autorecover and the next day I'll have a different DC reporting the error.
Did anyone ever get anywhere with this?
I am experiencing the same issue with UDT 3.2 randomly failing to DCs.
For my part I have noticed that manual polling via the UDT Job Status page seems to either: not do anything or is just failing immediately. If I kick one off by modifying a DCs polling interval, that seems to work much more reliably. No hotfixes on my install & it is a fresh server with no imported or upgraded Orion data.
I just opened a ticket, but I'm curious if there's any more data I can look for to help out support.
Orion Platform 2014.2.1, IPAM 4.3, NCM 7.3.2, UDT 3.2.0
I reported last that once I deleted a node and then re-created it the problem went away. Everything was stable for a week or so, but now that's changed. I have one node that is in an error state even after deleting and re-creating. I've re-created it 4 times now and after about a day the error state returns. I applied the hotfixes (1 & 2) last week, but that doesn't appear to have resolved the issue (in my environment at least).
I just got around to installing Hotfix 3 and so far it has not fixed the problem. I noticed that once polling fails on a DC, the next polling time does not increment. For example, the last successful poll for one of my affected DCs was 5 Feb at 8:48am. It still shows the next poll is scheduled for 5 Feb at 9:18am.
I've stopped deleting and re-adding the nodes and just basically ignore the "UDT Remote Event Log Jobs failed" message. However, I have noticed that occasionally it will indicate only 2 are in a failed state when there were 3 or 4 the day before. Apparently, some will eventually correct themselves only to fail again a day or so later.
Did either of you open tickets on these issues? I may have to open a ticket and I could reference them. I'm having similar problems with a 2-3 DC's (out of about 25) reporting that ominous message.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.