Enterprise feature set

[RDMTECH]

I think a great way to generate revenue with PL is with an enterprise version.  We can use this thread to start brainstorming on an enterprise feature set.  To get things rolling here are some suggestions:

1.  Silent installation
2.  Command line configuration
3.  Logging to Windows event logs
4.  Remote configuration
5.  Centralized GUI management of multiple servers/workstations
6.  Drag and drop 'prosuper.ini' to GUI

As I think of new features I'll add them.  If anyone else has suggestions please add them to this thread. 

[Jeremy Collake]

6.  Drag and drop 'prosuper.ini' to GUI

I've added this to the latest internal build, so it will appear in the next beta. Now for the others .

[RDMTECH]

Excellent!

[TKMTECH]

I first want to say i agree with all that RDMTECH has put forward.

I would also like to add:
1. Historical Data of the most used processes w/ average usage etc.

I would like to highlight Centralized GUI management for multiple servers/workstations and logging to Windows event logs as major requests that would be tremendous help in a enterprise environment.

[TKMTECH]

another thing to add that would also work in conjunction with my previous post would be a general reporting tool to put the data together.

[Jeremy Collake]

Thanks, excellent feedback, keep it coming.

I am going to begin work in earnest this week, so hopefully I can make rapid progress on this.

[Jeremy Collake]

Today I plan to implement the silent installer support. I'll try to provide all common options, like service and GUI start-up type, on the installer command line. This will require a bit of time to get fully implemented, so I may do so incrementally through this beta series.

[RDMTECH]

Excellent! 

If you cold provide some basic documentation to help us understand how to use the new functionality that would be great!

[Jeremy Collake]

Yes, certainly. I will document all this for sure.

I finished the necessary additions to InstallHelper and the installer script. The command line options all apply to InstallHelper as well; the installer will basically just be passing them verbatim to it. This may come in useful, as if I also add support to register the COM object via InstallHelper, one could perform the entire install with it.

I can tell you that the parameters I have so far are (subject to change):

/S   (silent)
/language=[...]
/gui_start_type=[all|current|manual]
/governor_start_type=[all|current|service|manual]
/rights=[highest|normal]
/logfolder=[path]
/configfolder=[path]
/importconfigfrom=[path]   
/username=[someuser]
/password=[somepass]

Of course, /username=x and /password=x are modifiers to /governor_start_type=service. Also, when NOT in silent mode, none of these command line parameters will apply, at least in the initial build.

I'll get them all properly documented once I finish the code.

UPDATE: I plan a beta release with this new capability tomorrow (Thurs 3/12) morning. I still have some testing to do. I'll also write up docs in the morning.

[RDMTECH]

This works out well.  I've got some time tomorrow to test.

[Jeremy Collake]

This works out well.  I've got some time tomorrow to test.

Great . I am about to begin basic tests here, it shouldn't take too long .. unless I run into troubles. I am quite pleased with the silent install feature, and enjoy having this capability myself. Anyway, it won't be long now.. Thanks!

Update: Ok, all is well. Building now. Upload in < 10 mins. Starting docs now.

[Jeremy Collake]

Ok, version v3.53.2 is now available. I also noticed that I didn't complete the beta release yesterday, so the selectable columns I raved about nobody got to actually see until now, oops. I had one false start a while ago, with a v3.53.1 release that I made a mistake with due to a phone call breaking my concentration, so I upped it to v3.53.2.

I am still testing, and making some changes, so the build could get updated throughout the day. Please let me know if you see any troubles, and please note that this is a very early beta with regards to the silent installer support.

I've also written up some docs, which I'm also still working on: http://www.bitsum.com/docs/pl/Command%20Line%20Arguments/command_line_arguments.htm

Thanks for your continued support, help, and everything

[RDMTECH]

Are there defaults with the arguments?

[Jeremy Collake]

Are there defaults with the arguments?

That is actually the chore I'm working on right now, making sure appropriate defaults apply for new silent installs, and that for upgrades the defaults don't override the existing setup. I should have all that addressed here soon. For this build, I suggest specifying all command line arguments. I'll post here when I've got the defaults worked out for sure.

Here is what I plan to default for new silent installs, which correspond to non-silent new install defaults:

1. GUI starts for current user (maybe should switch to all users??)
2. Core engine starts for all users
3. Normal rights
4. Per-user config and log

UPDATE: To answer your question, specifying a parameter without any value will default to the planned list above.

[Jeremy Collake]

Ugh, I just noticed that those docs sure came out ugly ;o. Don't worry, I'll get them looking decent after I eat some breakfast. I really intend to keep the docs updated and improved with each edit from now on, as they have had a tendency to become grossly out of date.

[TKMTECH]

Excellent RDMTECH and myself will be doing lots of testing of this today!  We will keep you posted.

[RDMTECH]

I just tested with my management system.  When I install as a service the "The Process Governor service was successfully installed." message box stalls the installation.  I have to click OK to continue.

[Jeremy Collake]

Ok, thanks, I missed that one. I'll get it now.

[Jeremy Collake]

I've uploaded a new build that fixes this. I didn't increment the version number, so please redownload last 3.53.2. You may encounter more minor issues, as I've really been testing internal functions and such here, my higher level testing obviously has only went so far. However, I did test service install this time, and all appears properly silent, barring erors.

I may also recode some of the command line parsing before final, as right now it doesn't really handle syntax errors as well as I'd like.

[RDMTECH]

Just got back from lunch.  I'll check out the new build right now.

[Jeremy Collake]

Ok, I just uploaded a new build that fixes the problem with spaces in parameters. Of course, you must encapsulate such parameters in quotations. This build also does other polishing. I did change the version number this time. I got in too big of a rush yesterday, and this morning, and perhaps released all this before it was ready. That said, it is probably close to ready now, though I still have plenty of internal testing and review to do.

New one is v3.53.3 beta .

[RDMTECH]

Ok the message is gone, but it would be nice to not have PL pop up after install.

[Jeremy Collake]

Ok the message is gone, but it would be nice to not have PL pop up after install.

Yes, I wasn't sure on that. I will add a parameter to indicate whether or not to show the main window after install, and default it to NO. I'll also add one to launch or not after install.

[RDMTECH]

That would be great.

[RDMTECH]

If you make any changes today I'm available to test.

[Jeremy Collake]

Thanks, I plan to upload a new build here in about an hour that adds a parameter to launch the GUI after silent install, or not. When the GUI is launched after a silent install, its main window won't be opened. Therefore, the new parameter is simply: /launch_gui=[true|false]

Would you prefer the default be that the GUI isn't launched at all?

[RDMTECH]

I think by default GUI should start, but remain in the system tray and not launch its main window.

[Jeremy Collake]

I think by default GUI should start, but remain in the system tray and not launch its main window.

Ok, that's what I had assumed. I'll have this new build up shortly.

After that, for today I'll likely move to work on a new license activation system I am implementing. In order to partner with distributors, I must control licenses, and this activation system will do just that. I have a Japanese company that wants to bring Process Lasso to market in that country. I won't be getting as much revenue per license sold, but hopefully real marketing will yield much higher volume. Anyway, I'm supposed to have this new activation system finished pretty soon, so have to get on the ball with it.

Update: I'll try to get the parameter defaults all defined today too.

[RDMTECH]

Ok, that's what I had assumed. I'll have this new build up shortly.

Thank you.

I have a Japanese company that wants to bring Process Lasso to market in that country.

Very cool!  I hope it's a fair deal and works for you.  Good luck!

[Jeremy Collake]

Very cool!  I hope it's a fair deal and works for you.  Good luck!

Thanks. I hope it is a fair deal too. I probably could have gotten a little more, had I been a better negotiator. That said, I got about what I wanted, and I think it is fair for both of us. As you can imagine, throughout the chain of distributors, each person takes a cut. That's ok though, as it gives them all incentive to sell more licenses .

...

I've now uploaded a new v3.53.3 beta build that makes the change to the way the GUI is launched after silent installs (minimized to tray), and also adds the switch to allow for not launching the GUI at all, in case anyone ever needs it. I didn't increment the version number this time, in an effort to reduce update fatigue for all those users trying to keep the latest build installed ;o.

[RDMTECH]

Grabbing it now.

[RDMTECH]

Question:

If I set it to startup for current user in a terminal server enviroment and there are multiple users logged on who will it start for?

I think we may need some type of password login or the ability to set it to start up for a specific user only.

[Jeremy Collake]

If I set it to startup for current user in a terminal server enviroment and there are multiple users logged on who will it start for?

By 'current user' I am always referring to the user context in which you are running the installer. So, it would be that user. I'll add some notes about this in the docs.

To specify precisely which users it will start for is something I'll need to think about. Modification of their individual HKCU 'run' registry keys is the appropriate way to do it. I'll work out the easiest implementation... It may not be today on this one though ;(.

[TKMTECH]

I have a Japanese company that wants to bring Process Lasso to market in that country.

That's awesome! I hope all works out well with that endeavor!

[RDMTECH]

To specify precisely which users it will start for is something I'll need to think about. Modification of their individual HKCU 'run' registry keys is the appropriate way to do it. I'll work out the easiest implementation... It may not be today on this one though ;(.

I understand you've devoted the rest of your time to your license system.  That's cool.  I just wanted to get it on your list.  I just think it would be better to specify a specific admin account for startup.  I would like to have the option of not giving users the possibility/temptation of changing settings or killing processes.

[Jeremy Collake]

Don't worry, I'm still focusing on Enterprise stuff in a big way. The licensing and activation system won't take much longer to finish, I hope. Then it'll be done. The Enterprise features are going to be an evolving work in progress for the foreseeable future.

I am tempted to just recommend using 'runas' to run the install as whichever admin user you'd like to have Process Lasso start for, as that will be the easiest way to accomplish what you want. I will keep thinking on adding the option to specify which user you want though, but it will likely end up doing an internal 'runas' to change user contexts. To specify multiple specific users gets a little more problematic, though is certainly possible.

[RDMTECH]

Sadly, locking down the application is necessary in the enterprise market.  I've already experienced users modifying PL's configuration.

From a silent installation perspective, I'm familiar with 'runas'.  You can use 'sendkeys' when it prompts for the user's password, but I've run into issues using 'sendkeys' with Vista/Server 2008/Server 2008 R2.  Do you use a different method?

[Jeremy Collake]

Sadly, locking down the application is necessary in the enterprise market.  I've already experienced users modifying PL's configuration.

Yes, I can imagine that is important. I will go ahead and implement the password feature to help protect against configuration changes. Of course, that isn't as secure as using file system permissions to limit the users' capabilities to modify the configuration file, but will probably be enough to thwart the average user.

From a silent installation perspective, I'm familiar with 'runas'.  You can use 'sendkeys' when it prompts for the user's password, but I've run into issues using 'sendkeys' with Vista/Server 2008/Server 2008 R2.  Do you use a different method?

Hmm, they probably protected the password dialog from emulated input in Vista+. AFAIK, I can programmatically launch a process as a different user without human interaction, so long as my code is provided with the user's password (re: http://msdn.microsoft.com/en-us/library/aa379608%28VS.85%29.aspx).

So, I suppose a customized mechanism is appropriate. I will keep it on the list .

Alternatively, you may also try this runas replacement that allows for specification of the password on the command line: http://www.moernaut.com/default.aspx?item=lsrunas . I don't know if it works or not in Vista+. If not, there may be others around.

[RDMTECH]

Excellent!

Thanks for the info.

[Jeremy Collake]

I am nearly done implementing the password support. It has been a tedious chore. Of course, this will continue to delay the current beta series from going final, but I -- for once -- don't feel any particular rush. Still, I hope to go final within the next week.

Update: The code is done,  but I have more testing and review to do before I dare to release this new beta. I will have it out asap though. I personally find this password support pretty nifty.

[TKMTECH]

Another feature that I just thought of.  Could you implement a recurring scheduled restart of services with this?

[Jeremy Collake]

Another feature that I just thought of.  Could you implement a recurring scheduled restart of services with this?

Hmm.. Yes, I could pretty easily implement that, with the GUI additions being the most substantial overhead. I'd need to create a new services tab for easier management of services, and a new scheduling system.

I think this could also be accomplished with the Windows Task Scheduler, scheduling 'net stop XXXX' and 'net start XXXX' executions. Is there a reason you'd prefer to use Process Lasso for that task? Perhaps just ease of use?

To help understand the need for this feature, I am curious in what situation(s) you find this necessary?

Thanks for the continued feedback and feature requests.

[TKMTECH]

Another feature that I just thought of.  Could you implement a recurring scheduled restart of services with this?

To help understand the need for this feature, I am curious in what situation(s) you find this necessary?

The reasons would be:

1.) I have a few windows 2008 servers that a minor service just randomly stop. And instead of running a script every 15 - 30 min, if it would be possible to have process lasso restart a stopped service would be nice since precess lasso is already running.

2.) Ease of use.

[Jeremy Collake]

Makes sense, I will see what I can do. It won't make it into this current beta series, as I am finally about to approach a release candidate. However, it may make it in the next one.

On other news, I am implementing support for configuration via Active Directory, in case any of you are interested. This has long been a much requested feature.

Thanks!

[TKMTECH]

Thanks

[RDMTECH]

Just downloaded and installed v3.60.  Works like a charm.  I haven't run into any issues in my environments.

I was wondering in the next beta series if you could implement an (silent install) option to only show the GUI/tray icon to specified user(s)?

[Jeremy Collake]

Great, glad its working well. It has also done well in my tests. I've run it through more tests than I normally do, due to the magnitude of the changes.

I'll try to get to that new feature in the next beta series. Is it the same as requested before: to specify for which users the GUI should start at login? Or do you mean to actually let the GUI start for those users, but just not show the system tray icon?

This also gives me an idea.. I didn't implement the list of users to start the GUI for because of the complexity of the code. However, I could more easily just let the GUI start at login for ALL users, but then immediately terminate when it sees that it is running under user Jane, Joe, or whomever not configured to have it start at login. The wasted startup time would be minimal since the termination would occur right away.

As always, thanks!

[RDMTECH]

What I'm thinking about is hiding PL (tray icon/GUI) to every user except those allowed.  It would be important to expose this configuration during the silent install/command line. 

Is it the same as requested before: to specify for which users the GUI should start at login?

I guess it is. 

I could more easily just let the GUI start at login for ALL users, but then immediately terminate when it sees that it is running under user Jane, Joe, or whomever not configured to have it start at login. The wasted startup time would be minimal since the termination would occur right away.

That sounds good to me.  Whatever works and is easier to implement.

Thanks for all the hard work!

[RDMTECH]

I finally have some time to test the silent deployments with my management system and I ran into an issue.  Can I use UNC paths such as '\\myserver\myconfig.ini'?  Or will it only work with drive letters?

[Jeremy Collake]

I finally have some time to test the silent deployments with my management system and I ran into an issue.  Can I use UNC paths such as '\\myserver\myconfig.ini'?  Or will it only work with drive letters?

The answer to this (very old) question is YES. Process Lasso can use UNC pathnames just fine so long as the user has access (obviously I suppose). If you've seen any problems with it, then please let me know.

NOTICE TO READERS: I had previously commented that I had not tested usage of UNC paths as global configuration and log folders, so came to update that post as it has now been tested in our ever-growing test bed.