New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


A weird question: PRTG services are killing Group Policy performance

Votes:

0

Your Vote:

Up

Down

I have an open ticket with Paessler but thought I'd throw it out here too.

I have PRTG (latest version) installed on a Server 2012 R2 VM, running under a Server 2012 R2 host. Plenty of resources - SAS drives, 8GB RAM allocated to the VM etc. The VM is a clean install.

When I RDP to the VM, I can login in about 1-2 seconds. That includes running a few GPOs to map drives, set registry settings, etc. Normal LAN stuff.

But when I install PRTG and start the two services, RDP to the VM takes about 150 seconds. Yes, 2.5 minutes.

If I then stop the PRTG services, logoff RDP, log back on, I am back on in 1-2 seconds. Start the services, log off, log back on, and it's 150 seconds.

Last week i started again. Created a brand new VM, installed PRTG, migrated my PRTG data as per the KB articles, and...same again, back to 150 second login with the PRTG services running.

WMIDIAG reports no errors on either the VM or the parent OS (other than an ASP namespace, which is normal when IIS is not installed). Also, I've enabled GPO logging and there's nothing obvious there.

RDP to any of my other VMs - similar spec - all take 1-2 seconds, and that's running the same GPOs (same username, same AD OUs and groups). It's ONLY my monitoring VM and ONLY when the PRTG services are running,

I'm at a complete loss. It looks 1000% like it's PRTG that's the cause of the slow logins - stop the services and login is back to normal speed - but I can't see any conflicts and I can't imagine what might cause it.

I'm open to suggestions please :-)

Many thanks

Jim

gpo prtg rdp slow wmi

Created on May 22, 2015 8:29:53 AM by  jimwillsher (20) 1



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

Update

The issue is fixed in the current stable version July/August 2015 Version 15.3.18. Please updated to the latest version and you shouldn't encounter anymore issues.

Best Regards,

Created on Aug 21, 2015 12:22:16 PM by  Luciano Lingnau [Paessler Support]

Last change on Aug 21, 2015 12:23:24 PM by  Luciano Lingnau [Paessler Support]



19 Replies

Votes:

0

Your Vote:

Up

Down

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.

Created on May 22, 2015 10:12:05 AM by  PRTG Tools Family [prtgtoolsfamily.com] (12,885) 3 4



Votes:

0

Your Vote:

Up

Down

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.

Created on May 22, 2015 12:51:12 PM by  jimwillsher (20) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on May 22, 2015 1:52:12 PM by  PRTG Tools Family [prtgtoolsfamily.com] (12,885) 3 4



Votes:

0

Your Vote:

Up

Down

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

Created on May 26, 2015 3:24:59 PM by  jimwillsher (20) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 3, 2015 11:52:05 AM by  jasonwiegel (0)



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 3, 2015 1:07:51 PM by  jimwillsher (20) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 5, 2015 5:55:49 AM by  Olivier RIEBEN (0) 2

Last change on Jun 8, 2015 9:25:03 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 5, 2015 6:55:57 AM by  jimwillsher (20) 1

Last change on Jun 8, 2015 11:38:35 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jun 8, 2015 11:45:50 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 8, 2015 1:31:13 PM by  Olivier RIEBEN (0) 2

Last change on Jun 9, 2015 8:09:44 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 9, 2015 7:24:35 AM by  Olivier RIEBEN (0) 2



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 11, 2015 4:23:19 PM by  Florian Schönemann (160) 2



Votes:

0

Your Vote:

Up

Down

Hi Olivier

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

Jim

Created on Jun 11, 2015 9:32:33 PM by  jimwillsher (20) 1



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 22, 2015 10:20:18 AM by  Florian Schönemann (160) 2



Votes:

0

Your Vote:

Up

Down

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

Created on Jun 22, 2015 2:46:16 PM by  jimwillsher (20) 1



Votes:

0

Your Vote:

Up

Down

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,

Created on Jun 22, 2015 2:51:34 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Aug 21, 2015 11:46:37 AM by  kube1984 (550) 3 1



Accepted Answer

Votes:

0

Your Vote:

Up

Down

Update

The issue is fixed in the current stable version July/August 2015 Version 15.3.18. Please updated to the latest version and you shouldn't encounter anymore issues.

Best Regards,

Created on Aug 21, 2015 12:22:16 PM by  Luciano Lingnau [Paessler Support]

Last change on Aug 21, 2015 12:23:24 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Aug 21, 2015 1:44:53 PM by  kube1984 (550) 3 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.