conners

This has been sorted of the built-in WMI asset discovery tool with the 12.1.0 hotfix 2

In version 9 the limit was 1000, but during the 10.0x beta the limits were reduced (500 -> 250 -> 100) to improve performance due to changes to the tech interface adding extra load

One quick thing on this are you using ticket or billing reports to get the time worked, if ticket reports then that is the cause of the issue as they will pull in any work time on a ticket that falls into the date / time criteria you use on the report, where as the billing reports pull in the work time that was only…

You can already do this by using MS Active Directory Federated Services and SAML2.0 authentication within Web Help Desk. Tomcat itself just does not have the ability to do Kerberos auth unlike IIS or Apache, but with using ADFS if the pass though auth fails it will just present the user with the login screen

The hotfixes only seem to show up in the portal and not on the release notes feed http://www.webhelpdesk.com/feed/

@djamesgraham what you seek is already in Web Help Desk http://www.solarwinds.com/documentation/webhelpdesk/flarehelp/whd_12-2-0_pa_en/default.htm#helpdesklinkunlinkincidentpro…

Why not just change Max Authentication Attempts Before Lockout in the authentication options

The Billing reports will give you the correct amounts of time, but as you say does not split in to various rates etc. Hopefully this is something that is addressed in the reporting update that they are working on.

Tick the SSL checkbox on on the incoming or outgoing to enable TLS

You should just need to rescan, otherwise remove the assets and then rescan

Is there a link to the updated API information including the new asset functionality?

How long till we see Java 7 support and at the same time support for SHA-2 signed SSL certificates as some CA's are pushing the use of SHA-2 (thanks M$) and they currently cannot be used with WHD and Java 6

By any chance the machine has rebooted recently and you have McAfee AV on the server?

Have a look at this - Musings on Information Technology - A view from the trenches: ADFS issues - ID3242: The security token could not be aut…

One thing to check in you LDAP settings is what you are using for the authentication attribute, if you are not using SamAccountName then the default claim mapping will not work and you will need to change to the appropriate AD attribute. If Loop1 can get logging of what is happening at sign on they might be able to shed…

Can you check ADFS logging on both proxy and give full error details at failure as that may point to underlying issue. Personally not sure not sure if the verification cert would make a difference, except if not installed in both ADFS and the proxy.

Oh and when I said roll back to 10, just do the database and then let 11 upgrade it

Turns out this is broken in 12.2.0 RC and full release

Oh and you will need to setup Attribute store connections via LDAP to the other domain controllers

You need to have multiple connection for different OU's

You only need 11, raise a support ticket and I'm sure they'll sort you out with a download. Or if your license is still the old type you should be able to get it from your customer portal

If you are running 12.2 / 12.3 get updated to 12.3.0 hotfix 3 as that has resolved issues with the FAQ links

Are you using an internally created SSL cert on the ADFS server? If so it is likely that the proxy does not trust the certificate, thus causing a SSL trust failure when it connects to the ADFS server.

Hi Glen, the ones I posted are the only ones available without using the action rules and custom tags

If you are going to be using ADFS for SSO you will need trusts between the domains and in ADFS on the claim rule within the RP trust you may want to use userprincipalname instead of samaccountname

For the dashboards instead of giving ticket access an idea would be for the dashboard to be created by a tech and published on the client view

best bet is to change the default binding to port 81, as even when disabled IIS will reserve the port bindings

Check in your \webhelpdesk\conf\whd.conf file and check that you have the following variable and that it is set as following; NO_REDIRECT=false

And you might want to try without verification cert

The SSL option is a bit of a misnomer, it is to enable TLS on the connection to the mail server (required on Exchange 2007 upwards and including office 365)