A weird question: PRTG services are killing Group Policy performance

Have you tried pausing all sensors (by pausing the probe's) ?

If that makes the difference you can work your way down to the group/device.

Many thanks for taking the time to reply. I've just tried that, with all sensors paused, and login is instant. So I've then resumed them all again, and login is instant again! very, very weird. It's as if I need to pause and resume them all after the services have been started, which seems a bit odd.

Could it be that there are/were background processes like recalculations running on your PRTG server?

This will show in the bottom right hand corner of the web interface.

Hi

Thanks for the suggestion but I'm not sure that's the cause. After a restart I can leave it for 5 minutes, 15 minutes, 5 hours....RDP is always slow. but equally, as soon as I have paused and restarted, RDP is always quick no matter how quickly I connect after the services are started.

Not to worry, at least I have a workaround.

Jim

Jim,

I have the exact same symptoms with my PRTG installation; this is a fresh installation of PRTG on Server 2012R2 with plenty of resources. I migrated the entire configuration in the KB article a few weeks ago.

I also recently noticed that our PRTG Core Server in services.msc is not running the 64bit service on my Server 2012 R2 box. On my Server 2008 R2 old box it shows the PRTG Core Server server running as a 64bit service. Same installation package. Very strange and by the way both versions of Windows are 64bit.

I get stuck on all GPO's such as applying group policy drive mappings, folder redirection, and each time I check the event viewer, the GPOs are delayed and take too long to load. The policies are hanging somewhere when the user logs in, but when I stop the PRTG Probe Service or disable it. I have no GPO issues when I login via RDP or Console

I am thinking that PRTG does not like group policy preferences that are applied to users when they login.

I have a support ticket in to PRTG.

Paessler have come back to me and said that they can't recreate the problem. But I'm glad, in a way, that it's not just me :-)

It's definitely weird. Yesterday I logged in and took 3 minutes. I've just logged in today to check my core service (also 32-bit) and login took 2 seconds.

Jim

I have also opened a case (PAE551491) for the same problem.

Paessler was also unable to simulate the problem.

We have found some interesting points with this issue:

• We have multiple computer and user GPOs applied to the server which run PRTG
• This only affect GPOs related to User, because they are applied at logon time
• This only affect GPOs using "User->*Preference*" kind of settings, we have other "User->Policies" settings that does not interfere with PRTG
• The wait time is proportionnal to the number of sensor; starting at 10 sensors we see the GPO application messages on login, with 1000 sensors we wait 12 min to login.
• Error messages related to GPO application abnormal running time are found in Windows event log
• If you stop the PRTG Sensor service while a user is waiting to logon, it immediately finish to logon
• This is not related to specific "User->Préférences" setting. You just have 1 setting like "create a shortcut" and you are stuck
• No abnormal CPU load is found during logon

Based on this, we have applied a workaround:

1. we have regrouped all settings in "User->Preference" in one GPO
2. we filter this GPO with a WMI filter that does not apply the Policy on the specific PRTG sever. This is not a big problem because the PRTG server is not used by any other people and if you apply at least the preference GPO one time, you are mostly happy.

But we have lost 3 days installing PRTG.

With all theses information, Paessler was still not able to reproduce. It seems that it affect winlogon process and any Windows ressource that is used by the PRTG monitor service. We think it it's related to the question of applying GPO in synchronous or asynchronous mode but we were not able to find the root casue at this moment.

Olivier

Yes I agree.

We have Group Policy Preferences applied, which do various things including drive-letter mapping, Internet Explorer preferences, setting a few registry entries to customise Windows Explorer etc.

We're also using item-level targetting, to apply these to just specific users.

Your workaround sounds fine. Ours is different, we just stop the service on the PRTG server via the sc command or via compmgmt.msc before we RDP. That way, login is instant. Sure, stopping the PRTG service is far from idea, but it's less painful than havign to wait several minutes to RDP.

I got as far as enabling GP diagnostics but there were no clues in the logfile. No reports of fails, locks etc., purely messages several minutes apart saying "starting XXXX" then "finishing XXX". It seems that PRTG just adds a truly massive bottleneck to whatever GPO is trying to do. I wondered if PRTG was somehow intercepting and querying something that the GPO process was doing, e.g. a hook.

Jim

Hello.

We hear you, we are aware of the issue and still trying to simulate this in our development environment.

In the meantime, as reported by other customers, we suggest not applying User Group Policy preferences to the PRTG Server as a workaround.

And to clarify some estipulation, PRTG is not hooking or checking GPO's, we currently don't check or interact with GPO's in any way. The issue is probably related to a single sensor type or combination of sensors that causes the issue to arise.

Hello Paessler,

I give you maybe two more tips to find the cause of this bug:

• you may see the same problem if you want refresh policies applied on the PRTG server using gpupdate force. If PRTG is running you are stuck. Then, if you stop PRTG Probe service, the gpupdate command immediately continue and finish.

• in my case, the W2K12 event log for Group Policy indicates a an event 5340 stating that policy execution mode is "Foreground Synchronous". I'am pretty sure that this directly related to this issue, ie when you set Policies implicitly or explicitly (in the GPO) that you execute Policies in Foreground you are also running these in Synchronous mode. Login in Asynchronous mode permit the user to login without the policies immediately applied but is sometime not desirable.

Please check to simulate this issue that you have a test Policy that is running "Foreground Asynchronous", and this should be confirmed by an 5340 event.

This will not give you the root cause but probably permit to reproduce the problem.

Olivier

Edit: Formating

Hi,

I have found a new workaround that would reinforce the theory about an issue related to group Policy processing in Synchronous mode:

W2K12/W8.1 has a new setting that is disabled by defaut on W2K12:

Computer Configuration\Policies\Administrative Templates\System\Group Policy\Enable Group Policy Caching for Servers

Enable it has solved my problem (99%) ie: my synchronous Policies are initially locally cached (next refresh) on the server and when processing occurs at login, Policy are taken from local cache and processing is back to asynchronous mode. This is confirmed by the event 6346 "Group Policy switched the sync mode process to async" and 5217 "Policy successfully loaded from local datastore"

And you are not stuck by PRTG at login.

But: this does not solve the logoff part (I have a script at logoff). You wait the same to logout.

So PRTG is preventing, in a way or in an other, the access to the network to get on-line Policy content.

Would be interesting to know if other people affected have the same improvement.

Olivier

Hi,

I migrated from Server 2008 R2 to Server 2012 R2 and thought I was the only one having this problem on our PRTG Core Server when applying the drive mapping policies. I hope, Paessler can reproduce it in their testlabs soon. I'll try to look at GPOs with my collegue next week, maybe we'll find something.

Florian

Hi Olivier

So far, that workaround seems to work for me too. Well discovered!!!!

Jim

Hi everyone,

I have non of your mentioned problems. The only policy taking long is the drive mapping policy on the PRTG servers (on both cluster nodes). Any ideas, what could cause runtimes for drive mapping policy of around 9 minutes?

Florian

Paessler have sent me a private build containing a fix, and I can confirm that it does fix the problem. So hopefully the fix will be included in the next public release.

Jim

UPDATE

We were able to track down the issue and it should be fixed in the coming version, in our test environments and at a few customers the new build performed very well and as soon as our QA Engineers complete their tests it should be released for general availability.

Our thanks to everyone for the details on reproducing and tracking this issue and also on the workaround which helped many other customers with the same issue.

Best regards,

I've been having the same issue for months now, exactly as described in this article, glad you guys are aware of it, do you have any idea what version or time frame this fix will get released, going to apply the fix above will hopefully take care of my issue. Thanks

I'm so close...im on 15.3.17.xxxx. I'll update to the new version. Thanks