JeffVandervoort

First, create a Scheduled Task to bump the service. (NET STOP "Service Name" && NET START "Service Name"). Then, in the Rules tab, create a Rule whose Condition is the service is using > 60% CPU or > 2GB RAM. The rule's Action would be Run a Task, and select your Scheduled Task.

Typically, in a Remote Desktop hosting environment, we want to keep the per-user memory footprint as small as possible. 8 MB doesn't seem like much on a typical desktop or server, but on an RDSH, every byte counts, because RDSH capacity is generally determined by RAM. My understanding from another thread, here, is that PCMONTASK was added for the screen view feature, and that's all it's used for. Even at 8MB, this one task increases the memory footprint of an RDPINIT session here by about 50%, and is far larger than any of the other per-user "overhead" tasks we run here. By "overhead", I mean the mimimum background processes that are not what the user logs on in order to run, but are needed to maintain the session, security, application virtualization, etc., and which run in the user's context. The task is launched, whether or not the Screen View option is selected. And we do not use Screen View here at all. I'd ask that the registry entry in HKLM\...\Run to be deleted if the Screen View option is de-selected. That's a best practice, anyway: No unnecessary processes running. And it might be a good idea to add "(Requires approx. 8-9 MB per user; not recommended for Remote Desktop Session Hosts)" to the Screen View control's caption in PC Monitor Manager. Going forward, if you have other plans for PCMONTASK, please make sure the features that require it are identified in the UI, and make sure that the other parts of PC Monitor will work without it.

Another scenario: A Win 6.x file server has UAC enabled, and a shared folder has an ACL as follows: Administrators: Full SYSTEM: Full DOMAIN\SomeGroup: Modify Sysadmins are members of Local Administrators, but are NOT members of DOMAIN\SomeGroup. This is intentional. In this scenario, in order to access the folder, an admin either has to make himself a member of DOMAIN\SomeGroup, or by clicking "Click continue to gain access" when prompted. Either is an auditable security event, and Microsoft provided this functionality in UAC to protect against rogue admins. If it becomes necessary for an admin to have access to this data in the scope of his duties, that's fine. If he has no business being in that folder, he's warned, or terminated, and possibly prosecuted. PC Monitor Service, however, because it runs as LocalSystem, can make that sensitive data available via e-mail to any PCM user who wants it, provided that file browsing is enabled. Remote file browsing can be very useful to admins if they're browsing folders they are responsible for maintaining, so one would want to enable it. But PC Monitor file browser makes an end-run around ACLs, and provides access to all folders on the system. You can warn people not to enable file browsing on servers containing sensitive data all you want. But there is a security axiom that states that ALL data is sensitive when the wrong person has access to it. And servers are dynamic. Let's say this is that one-and-only server in the world that is so free of sensitive data you could publish its shares on anonymous FTP. So file browsing is enabled on PCM. That PCM setting is going to be long forgotten when an admin sets an ACL that he believes will protect data from falling into the wrong hands when sensitive data is finally placed on it. Again: An AD-authenticated session handles this situation automatically. The admin would have remote access to whatever they needed to do their job--and nothing beyond.

Squeaking wheel gets the grease, they say. Push management was, IIRC, the first thing I posted about here, and it remains my number one unfilled need. If I can recruit others to "me too" the idea, perhaps it will become a higher priority. As Simon's request was push-management related; I couldn't miss the opportunity. Thanks for providing this forum for your customers to help shape PC Monitor, and for listening.

"if you decide to "share" your account username/password with other users/devices then it is you that "makes every user an uber-admin"." Exactly, Marius. You've just crystalized the problem. That's why I'd have to stop using it. Because all PCM devices share one username & password, and the same (very elevated) privelege level. PCM users are admins, but systems of any size restrict admins to permissions that apply to their specialties, and nothing more. When my future (say) Exchange admin logs on and opens EMC, they can do whatever AD authorizes them to do, which will be pretty much everything Exchange-related. But as little as possible that isn't Exchange-related. The Exchange admin's responsibility probably won't include shutting down DCs or file servers, because that's someone else's responsibility. From RDP or console, they can't do anything I haven't authorized. From PCM, they can do whatever PCM can do, anywhere in the system on which they have an authorized device; even if that authorization SHOULD be limited. But if I give them PC Monitor to help them manage Exchange, they can remotely shut down DCs or file servers or RDSH's--because LocalSystem can. Or run scheduled tasks, or open priveleged console sessions, and whatever capabilities you add going forward, and on any of them that they have access to through PCM. And that granularity may or may not take place on the computer level. A single computer can have multiple roles administered by different personnel. AD can keep them separate. PCM can't. With AD, they'd enter their user creds, not PCM creds. Device auth is then separated from user auth, as it is in every modern OS. And when an admins account is terminated, or permissions changed, the admins PCM access changes with it, automatically. And there's no device auth at all for Dashboard. I'd have to personally enter credentials for all Dashboard and mobile installs in order to prevent Dashboard from being used to get around device auth. And my only recourse upon terminating an admin or discovering a security breach, would be to issue new creds on the service itself, and all PCM Dashboards, mobile devices, and Manager installs. One at a time. Yuck. Finally, there's no "read-only" in PCM, unless I've missed it. A device either has all access or no access. Going back to my future Exchange admin, they might not be allowed to manage DCs, but they might very well want to know if they're up or posting errors. A "read-only" device account would permit that, and would be a good interim enhancement. My inclination would be to give all admins "read-only" access to all servers, if only because if the right admin isn't watching, someone else might be, and could give them a heads-up. But, again, an AD login would make sure it happens automatically, instead of splitting off PCM settings as something different. Some businesses may not care, and some admins may never realize PCM is giving admins LocalSystem permissions. But my business, when it reaches critical mass, after pilot, will absolutely require AD auth for admins, in order to meet its committments to its customers. You'd certainly not be the only 3rd party to offer AD auth to augment or (usually) replace their own built-in auth. Symantec Endpoint Protection, Raritan KVMs, Cisco & OpenManage come to mind; there's certainly many others. Including, obviously, every MS server technology. What these products have in common: An acknowledgement that AD works awfully well to provide granular security for admins, and that these products can all be misused if the wrong admins (or ex-admins) have access to them. Right now, PCM lacks that, and I'm hoping you can change that by the time I need it, because I'd really like to keep using it.

This might be useful to some, and would be easy to implement as an interim step: Allow certain devices to be "read-only" devices that could receive notifications but not issue commands.

I'd like to be able to tell PCM to monitor all HDDs, instead of specifying one at a time. And as HDDs are added and deleted, automatically monitor them, too. It's pretty rare to find a disk I don't care about! HDD monitoring should also report Windows' storage Events (from NTFS, Disk, ATAPI, SMART...all the built-in stuff) without having to explicitly set up Event Log notifications for them. And since we're on the subject again, a repeat request for monitoring mount points and not just drive letters.

I'm a big believer in principle of least permissions. AD includes several built-in levels of administrative permissions, and allows creation of many more through Delegation and Group Policy. PC Monitor makes every user an uber-admin, because it runs as LocalSystem, one of the most powerful accounts in a system. I'm a one-man shop at this point, but hope for big growth when I'm in production. There will come a time, possibly fairly soon, where I will no longer be able to use PC Monitor because it does not allow me to properly secure the system. I'd like for PCM to impersonate users, and use AD to determine what they are permitted to do, which servers they're permitted to control, etc. This is a non-trivial request, and I'm sure it will take a while to get done. Hope PCM gets there by the time I need it! (Now, watch Marius respond, "That will be in version 3.0, next week.")

Regarding why one shouldn't allow all devices, here are 2 good reasons off the top of my head: Mobile devices get lost and stolen, and employees get terminated. If all you have securing PC Monitor--a VERY powerful utility usable unsupervised and off-premises, access to which should not be granted lightly--is the username & password, you have to change that on every device and for the service itself. No thanks! <editorial>Unfortunately, Simon, PCM is not very enterprise-friendly when it comes to pushing changes. (Please join me in making noise about that!) Apparently the PCM server includes some sort of push config capability; maybe that would address this. I've not purchased it yet; I probably will when I'm in production with it. But I feel that there should be SOME way to do a home-brew push config with Group Policy Preferences/Registry or .reg files without that expense, even if not supported, as there is with most programs. The design of PCMs registry settings prevents that. And even a handful of computers is too many to manage one at a time.</editorial> I've been able to push config changes on machines that have common settings, but this particular setting doesn't lend itself to that (with good reason) because each computer appears to have a different hash for mobile device IDs. If there's a solution for that, it will need to come from Marius.

That's great to hear...but it wasn't really what I was asking, so I guess I didn't explain it very well. And since then, I've rethought what I'm asking for anyway! So here's version 1.1 of my request: Here's one of several relevant scenarios: Dell OpenManage Server Administrator (OMSA) doesn't log very many events, but the ones it logs are usually related to storage problems. So if OMSA has anything to report, I want to hear about it. Therefore, I have set up Notifications to alert me to all OMSA events. Currently, in order to receive Critical notifications for Error events, Elevated notifications for Warning events, and Normal notifications for Information events, I have to map Severity to Priority myself by settng up 3 separate notifications. What I'd like is to set up one notification for OMSA, with Critical, Warning and Information checkboxes turned on, and have PC Monitor set the Priority level at run time, to match the Severity of the Event. I'd like to see a new "Automatic" setting on the Priority dropdown that does this. OMSA is an especially good example, because I don't restrict its notifications to a few IDs. But I find that in general, I want the Event Severity to match the Notification Priority.

Lots of admin types just about live in vRD. (If you've never heard of it, check it out: www.visionapp.com.) Happy to report that PC Monitor Dashboard 2.7 can be installed as an "External App", and 90% works. The 10% that doesn't is the menu bar. But I don't use the menu bar in Dashboard much after it's installed, so that works for me. My settings in the Dashboard external app properties' "Options": Wait for exit: On Max wait time: 2 Try to integrate: On Max wait time: 2 Start as shell process: Off [Edit] Since writing that yesterday, I've decided to go for the record for the most tortured way to use Dashboard. Not only because it's highly useful in my hosting service environment, but also, well, just because I could. Disclaimer: I'll leave it to MMSoft to advise whether any of this is supported. My guess would be that it isn't. But, empirically, it works. Except the menu bar. So there. YMMV. Dashboard 2.7 can be run (sung to the tune of Partridge in a Pear Tree): In vRD 2011, as an integrated External App, as explained above. As a virtual application sequenced with App-V 4.6 SP1. As a-- virtual application sequenced with App-V 4.6 SP1 in a WS2008 R2 RemoteApp. [*]As a-- virtual application sequenced with App-V 4.6 SP1 in a WS2008 R2 RemoteApp and published via Forefront UAG 2010 SP1. [*]As a-- virtual application sequenced with App-V 4.6 SP1 suited with vRD 2011 as a virtual application via DSC, and (this next was the ultimate goal) (drumroll please) (deep breath...) [*]As a-- virtual application sequenced with App-V 4.6 SP1 suited with vRD 2011 sequenced with App-V 4.6 SP1 via DSC in a WS2008 R2 RemoteApp and published via Forefront UAG 2010 SP1. Number 6 kind of stretches the limits of all 137 technologies it employs, so its vRD settings are a little gentler: "Try to Integrate" is set to min. 5, max. 5. And since, without a picture, it didn't happen, I've attached a screenshot of number 6, untouched by Paint.net, save for the obvious blurs to protect the innocent.

In Desktop 2.7 or Manager 2.7, create or edit an Event Log Notifications. Grab a corner of the dialog box and gradually make it smaller, watching what happens as you do so.

When creating a new Event Log Notification, typically I want the Notification to have a "Priority" that maps to its "Level". So, please make the Priority default to whatever is the highest Level of the checkboxes that are selected for the Notification, but still allow the user to select a Priority they prefer. By default, then: Error = Critical Warning = Elevated Information = Normal. Or Low. Not sure of the difference. What's the difference between Low and Normal in PCM Priorities?

Agree with some of your points and could add a few...but was trying to avoid an OS war!

Okay, loving Dashboard 2.7, and can check off items 3, 4 and 5 from my list, above. Still looking forward to 1 & 2, especially; 6 would be nice to have.