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.

OK...there's an easy fix! 1. Close Dashboard. 2. In REGEDIT, delete HKCU\Software\MMSOFT Design\PC Monitor\Dashboard 3. Open Dashboard and reconfigure.

Don't imagine there will be a cure for this short of reinstalling Windows, but I'll ask anyway... Win 7 x64 SP1. Help/About in Dashboard 2.7 tells me that I should get tray notifications of new alerts, and that feature is enabled in Tools/Options/Runtime. Not only do I not receive receive notifications, there doesn't appear to be a tray icon any more. I've uninstalled & reinstalled; no change. I know the tray icon USED to be there. The one that didn't do anything. Probably as recently as v2.6 but I couldn't swear to it. I've installed it on 2 other machines and the tray icon is alive and well. So it's just this one machine. Now that it actually does more than occupy space in the tray, I'd love to get it back if there's an easy fix.

Apple does do a better job supporting consumer products than anyone else. They'd better, for what you pay for them! The companies that offer enterprise products also support them pretty well (mainly thinking Dell & HP). With rare exceptions, we can skip over the "Is it plugged in?" script and get straight to the problem, and I'll have the parts or a tech next day or within hours, depending on the warranty I buy. But those same companies' consumer product support is as bad as Sony & Acer. Oh, yeah; forgot, I had an Acer notebook too, once. Slim, lightweight and better-than-average design, but very fragile. And yes, gruesome support, though better than Sony. Sounds like I'd better stick with enterprise products!<sigh> OK, I'm done hijacking your thread. Sorry!

I do like the auto-update...can't wait for v2.8 to see it work! And on 2nd thought, I guess the "groping" feature gives PCM that, well, personal touch that lesser admin software lacks.

Depends...Windows has had a power management API since Win 98. Some, like APC, actually support it with some models. Virtually every notebook uses Windows API for power management, for that matter, even if they supplement it with proprietary stuff. But, like Paul says, simulate a power failure and look in the Event logs; Windows power API writes events to it, and so do most 3rd parties I know of.

Daniele, off-topic, but would be interested in hearing if Sony's support is any better than it used to be. They make the world's most beautiful notebooks (nicer than Apple, by FAR) (and I'm an ex-architect who knows and appreciates design) but my VAIO's failed early and often, and support was gruesome. As a result, I haven't bought one in about 7 years. Lemme know how it goes. VAIOs do make a good impression on clients, I've found, and I'm launching a new biz (two, actually) where I'll be interfacing with lots of them...at least I hope so! My Dull Dell is nice enough, but doesn't have the same, visceral, "this guy knows what he's doing" impact.

Nice touch...thanks!

Marius sez: PC Monitor Dashboard 2.7 has been released It adds auto-update support, computer groping and other improvements. -------------------------------------------------- (Emphasis mine). Don't get me wrong...I do like Dashboard 2.7. Really. I do. But...while lots of us geeks here are into computers, I've never once, in 20 years in IT, groped a computer! And if I did, I'm man enough to do it myself; not depend on PC Monitor to do it for me. Sorry, Marius. Too weird for me.

The reason it's not supported is that there is no Explorer shell in Core. In Core, the common file dialog is the one you'll remember from Win 3.x. For an example, click File/Open in Notepad on a Core box. Don't know how you call it with .Net, but that's what you'll need to do.

Coulda sworn I'd posted this a long time ago, but I guess not. On a WS2008 R2 Core machine, when you click Import or Export, PC Monitor Manager vomits forth the .Net message at the end of this post. (Gee, .Net, are you sure this is ALL that's wrong??) Thus it's not possible to import or export with a Core box. Now, I'm no .Net expert, but I know there's no such thing as a Vista common dialog in Core! See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.Runtime.InteropServices.COMException (0x80040111): Creating an instance of the COM component with CLSID {DC1C5A9C-E88A-4DDE-A5A1-60F82A20AEF7} from the IClassFactory failed due to the following error: 80040111. at System.Windows.Forms.OpenFileDialog.CreateVistaDialog() at System.Windows.Forms.FileDialog.RunDialogVista(IntPtr hWndOwner) at System.Windows.Forms.CommonDialog.ShowDialog(IWin32Window owner) at .(Object , LinkLabelLinkClickedEventArgs ) at System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.Label.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.239 (RTMGDR.030319-2300) CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- PCMonitorManager Assembly Version: 2.6.4334.16923 Win32 Version: 2.6.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/PCMonitorManager.exe ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.235 built by: RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.236 built by: RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- MMUtilsFw Assembly Version: 3.3.0.0 Win32 Version: 3.3.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/MMUtilsFw.DLL ---------------------------------------- PCMonitorCfg Assembly Version: 2.6.4334.16912 Win32 Version: 2.6.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/PCMonitorCfg.DLL ---------------------------------------- PCMonitorEng Assembly Version: 2.6.4334.16918 Win32 Version: 2.6.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/PCMonitorEng.DLL ---------------------------------------- PCMonitorTypes Assembly Version: 2.6.4334.16908 Win32 Version: 2.6.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/PCMonitorTypes.DLL ---------------------------------------- System.ServiceProcess Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.ServiceProcess/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.ServiceProcess.dll ---------------------------------------- MMCommonFw Assembly Version: 3.3.0.0 Win32 Version: 3.3.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/MMCommonFw.DLL ---------------------------------------- System.Management Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll ---------------------------------------- TaskSvc Assembly Version: 1.5.3993.39231 Win32 Version: 1.5.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/PC%20Monitor/TaskSvc.DLL ---------------------------------------- CustomMarshalers Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/CustomMarshalers/v4.0_4.0.0.0__b03f5f7f11d50a3a/CustomMarshalers.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.233 built by: RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Web Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.237 built by: RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Web/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Web.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.233 built by: RTMGDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- Accessibility Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- System.DirectoryServices Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.DirectoryServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.DirectoryServices.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.