Suggestions - dhm, dm, dcc

[Xander]

dHM:
Blank system identifier should default to HKLM\SOFTWARE\Foolish IT\D7\Reports\ClientName | %ComputerName% | %username% for reports/etc. So something like "John Smith | HP-Owner | John"
Since a lot of us, I assume, do set up the client name when doing a repair/etc, there should usually be something in there. If it's not there, a client-friendly popup comes up asking for ClientName with, perhaps, text taken from the AltLanguage. "Please enter your first and last names"

dMaintenance:
Send the email to the client not me? I don't know how much, if any, rewriting this would take but the plan I'm thinking of implementing would send the finished report to the customer and not to me. I'd be telling them that, if anything seems terribly out of the ordinary they could forward it to me. This way, as sales progress, I might see a few reports a week, and not dozens.
Would the solution to this be to create a new installer for every customer

Could the email address be taken from the subscription? This would probably require adding a field. If the field is blank, it would default to the tech's email from the config but the presence of a subscriber email could supersede that.

dCloudConsole:
Is there any way to specify when a subscription expires? I'm only seeing Name, dS (yn), dM (yn). If we could specify a date (with a default period of, say, one year), that would be splenderificus.


In a nutshell, I'm looking for ways to be able to send someone a download link and, once that system shows up on my cloudconsole, I can configure the rest of their info.

[Nick]

You might have missed the boat on something, I'm no longer developing dMaintenance, DHM, dEvent, or dSupport. They have been retired for sale on my website pretty much right after I got dSS released and stable, and in fact, next time I do some spring cleaning on the old PC, I think the source will be deleted entirely for those legacy dApps, just so I have a good reason not to fix or improve anything with them. As much as I hate to retire a product that I've sold to people, who would otherwise expect me to continue developing it forever like D7, they have all been completely replaced by dSupportSuite which has all of their functionalty and then quite a bit more, with the added benefit that all the various functionality in dSS works together, not separately like the other apps, so reports can be consolidated and other information shared between functions. I only wish I could get everyone to upgrade to dSS so I could just erase those apps from my servers/cloud/etc.

That is exactly why I'm practically giving away dSupportSuite to anyone who bought the legacy dApps. My vision is to develop only two apps, one for the tech (D7) and one for the tech's clients (dSS) and no more. My attention is too divided between different apps and it was starting to wear down on me.

Let me address your suggestions with dSS as the solution:

dSupportSuite does store client information, name, phone, and email in the registry for usage elsewhere. D7 will have the ability to pull the client name from dSS for it's reports when used. I'm not doing it yet, but what I can do is have dSS pull D7's client name IF it cannot find its own.

Maintenance reports - in dSS you can configure them to go to you, the client, or BOTH. The maintenance emails could be a little more friendly, but they aren't bad. As long as you don't include the heartbeat or event logs in the report, it will remain simple.

Automatic expiration - I got nothing for you there right now, but I can *imagine* a way to do this with dSS.

For the nutshell, you can create a custom installer for the client, embed it with their client ID, name, email, and phone. You can configure it any way you want to for that specific client too before deployment. Then upload it to your webserver and send them the download link just as you imagine. Once installed it will appear in your dCloudConsole and you'll need to do nothing else - but from there you can customize it further (if you didn't already when you created the custom installer.)

[Xander]

Yeah, I was missing a boat at least Like I said in the other thread, I was thinking of dSS as more of a manager for the others. Got that straightened out in my head now. I'm going to blame this cold that started yesterday.

You saw my other thread on TN on what I'm conspiring to do. But, for those who haven't, the plan would be to install dSS on residentials as an alternative to my GFI RMM offerings at about half the price. This would be more self-managed in that I'd like the reports to go to them, not me, and they might have the option of forwarding them to me for a second opinion.

Okay, so a fresh installer for each customer and, with it, a separate ClientID. Okay. The hurdles I'd foresee is that the admin email is within the Config so I'd have to reconfigure each one separately (goes back to the subscription email idea). Since my configs should be the same, I can use templates to effect a Master Config and push that using "load to client ID" ... can it push changes across multiple IDs or is that better done by ctrl-selecting the IDs and Reconfiguring en masse? (See hurdle)

I see that I can reconfigure more than one ClientID at a time but, if their Admin emails are different, wouldn't that overwrite one or more of them?

I'm speaking circularly now and this cold is getting the better of me. I'll stop now. I think you get what I'm trying to say.

[Nick]

Yeah I do. The admin email is always your email address, it should never change across configs (because as I explained in the reply email to you I just fired off, the admin email is used as the REPLY-TO email address when dSS sends emails to the client email address, so they can just click reply to contact you... and vice versa with the emails that you would receive, should you choose to receive any.)

The client email is what you want different for every config -- and that isn't stored in the config actually but in the registry. It can be embedded in the custom installer and automatically placed in the registry at the time of install, else you can choose to prompt for the email/client info at install time - for a more generic version of the installer.

(now you can see why I don't call the admin email address a 'default email address' in dSS like I did in the other apps...)

When reconfiguring, you are only working on one Client ID's config at a time, however yes, you can *apply* that same config you are working on and upload it to dCloud for multiple client IDs at the same time using ctrl-select. Applying the same config to multiple client IDs will not affect or overwrite their client email address.

dSS concepts are a bit different than the older dApps because I've had a lot of great feedback on making the process as flexible as possible. Here's what you need to do.

1. Create a template and configure it the way you want for your home user plan.

2. Now every time you get a new client on the plan, you can just create a new client ID for that customer, load the template in, and upload that config to dCloud. You won't have to change a single thing in the config after loading the template! There is no reason to hit the reconfigure app button. You can simply upload it to dCloud after loading the template.

Now to distribute the installer to the client, you can do this in several ways.

Do NOT use the create generic installer option in your case. What this does is allow the person to select the client ID at the time of install, or create a new one (which is effectively a new 'subscription'!) So never use that unless YOU are the one doing the installs. Using the standard create installer option will embed the client ID into the installer, so the person doing the install doesn't have the option to mess with your client ID list.

3. So what you want to do instead is use the standard installer option, and embed the client name, email, and phone in the installer so it gets automatically placed in the registry during install. With this method you can deliver a fully customized install to a client without worrying about them entering in their details during install. alternately you can check to open config lite after install if you don't have this info -- but you will still need to create a separate installer for every customer as the Client ID (your 'subscription' identifier) will be embedded in the installer.

There is a third way but this won't serve your purpose, and is mostly for businesses. With this method you can re-use the same installer for different PCs belonging to the same client ID which will have different users sitting at them. Basically use the same method as above (standard installer - created for specific client ID) but you can skip embedding the client info, and select the "Open Config Lite after install" option before creating the custom installer. Obviously during install, a 'lite' version of the config pops up with only a few simple options to modify which of course include the client info fields. So whoever is doing the install (i.e. your client) must enter in their own name/email/phone - but they don't have the option of choosing their own Client ID - as they don't even need to know what that is or does.

[Xander]

Actually, the generic installer might serve my purpose more often than not since I'd expect most of the sales of that service would be at the end of a service call or before it leaves the bench where I'd want a handy dandy installer ready to go. They say Yes, I run the generic, fill in the blanks and we're done.

The "before it leaves the bench" part is tied back to the expiration date. If they don't go for a full year right off the bat, I think I'd like to try providing a one-month trial where, once it's done, it reverts back to a limited dSupport. Having the expiration tied into the installer details would be ideal for both of these circumstances. One installer for "1yr", one for "1mo". For that matter, doing the install assuming it's a trial would get them into the console and, from there, I could bump it up later to a 1yr (but being able to have separate installers would still be advantageous).

Just to re-check, I can have one single clientID "Residentials" and I can reconfigure that over time and those changes will be pushed to clients without affecting their subscription info? I think I'm having trouble connecting how the ClientID and subscription are linked.

[Nick]

The client ID is synomous with a subscription - that is what the 'subscription' is, so no you cannot use a 'residential' client ID for all of your customers (that should only be done with biz clients having multiple PCs on the same subscription,) so each one of your home users needs a separate Client ID else they will all be sharing the same subscription!

You can still reconfigure the changes over time and push them out to all clients without affecting their individual subscription status - just load your template into a client ID (any one will do!) make your changes, then ctrl+select all of your home users and hit the upload config button. You will see it upload the config once for each client ID selected.

Yep, a generic installer is handy to have before they leave the bench - in fact that's the only one you can upload to dCloud and exactly what D7 and dCloudLauncher are designed to download. It's just that if you are sending the installer to a client for THEM to install, you want a custom one (whether the client info is filled out or not) but NOT the generic installer!

[Nick]

oh, also I can think of two ways to do an auto-expire subscription, will need a bit to decide the best method.

[Xander]

Okay, so if every 'account' is managed through a ClientID then what are the subscriptions for? If they're synonymous, why are they separate?

I'm wondering, since I'm seeing "subscription manager" under legacy, if I'm doing the same thing as when I started this thread and bringing an outdated mechanism into the mix. The more I think on that, the more likely it seems.

I'm now rephrasing out the word "subscription" as I think it doesn't apply any more. So, then, what I *think* I'd want to see would be the Template Manager have the ability to tie an expiration time into the template so that when that template gets applied, the ClientID that gets created by the generic installer (and config lite), automatically gets a ___ day time limit. I could then go into the new ClientID and, if they've paid, bump that to a year.

Am I getting it? I could have put all this into emails but I'm guessing I'm not the only one wrapping their heads around the changes

[Xander]

I was going to ask about creating a Temp clientID that I could send to a customer and then, once it's installed, fill in the blanks from my side BUT that would require being able to rename an ID.

[Nick]

yes, subscription mgr is for the legacy apps, not dSS.

renaming a client ID so far isn't possible - can't actually think of a good way to do that without breaking the client's connection to it.

but all you need to do is create a unique client ID for the installer - if you don't have the info to fill in the name/phone/email, then enable the config lite option during installation, so the customer can enter it in themselves. You just have to instruct them to do so - and hope they actually do it.