OEM Preinstallation of dSupportSuite

[Nick]

This is a great addition, but it leaves something to be desired. If a /PreInstall command line parameter was created it would be much more automated when formatting many computers at the same time. /PreInstall would differ in the following ways:

1. A generic installer could be used during Audit Mode (not silent)
2. The technician enters the ClientID, Name, Phone and Email of the customer.
3. Nothing happens, the appropriate registry entries are made but there is no NewInstall email or any contact AT ALL with the dCloud.
4. The finalizing of the installation (New Install) email and client creation on the dCloud is done when the application is run the first time.
5. I would then script it to run with /FinalizeInstall which does not display a GUI and is completely silent from the command line.

This would be ideal. I imagine it would be a little out-side-of-the-box but it would save a lot of time!

Thanks,
Ray

not seeing how you can't do what you want, but I also don't understand everything you want. let's go over this step by step.

1. ok, do it.
2. ok, do it. select a common client ID you created for the generic installers, but enter in actual client info in config lite prompt as desired.
3. shouldn't matter what happens with dCloud at this point, to you it shouldn't mean anything. Just ignore the automated new install email for the generic client ID.
4. run dSupportSuite.exe /set /newclientid=Mr Roboto
5. ??? what are you trying to accomplish here? near as I can figure you mean step 5 is what you do to make step 4 happen???

[csc]

I'm trying to automated step 5. If my process was used then step 5 would be become a universal command line which I could put into my ISO files. I'm not customizing every individual windows installation by writing a script for each one, I'm using one script on every machine. It will know the client ID and the phone, email and phone because I will enter that information accurately when I install dSupportSuite in Audit mode. Let me describe it another way:

So if I'm working in a computer shop, and I have an inventory of computers with price tags (it's been a while...) I would preinstall Windows on all of those computers. I would format the drive once I open the package and create my own Windows image and recovery partition for that computer. Then I would put the computer back on the shelf, and wait to sell it to the customer. I'm not going to reopen the package and write a script for that customer when they purchase it, I'm going to identify the computer by the client ID within the dCloud so the correct configuration can be applied to that customer. But heres the thing. I might have 20 computers on the shelf I have not sold, and I dont want the list of all 20 to be placed in the dCloud. I don't want them all to have the same identity either because the Client ID is a unique number for every machine. When a customer decides to buy that computer, I won't have to open the package and customize it again. It's been "pre-customized" in a sense. There needs to be a generic command line to run on OOBE which will trigger the New Install email process and the "create folder on dCloud" process so I can run the same command on every computer.

[Nick]

I get the concept of preinstalls, audit, and oobe behaviors -- I guess what I don't understand Ray is how you can assign a unique client ID to each install without putting your hands on it personally. Maybe I'm being dense right now, but how can you assign a unique ID either during audit phase or during an oobe phase? Unless you are generating them named with sequential numbering or something... but then how to tell who has what?

I see you say originally that in step 2 your tech is putting in the info manually -- well that won't work obviously if you don't know who is going to buy your PCs yet. On the other hand if your example doesn't really apply to what you need to do, and you do have a tech in step 2 putting personal touches on the PC for the client during audit phase, then I don't understand why you're trying to automate step 5 when you aren't going to automate step 2? what would the difference be in doing it vice versa like I suggested, automating step 2 (as I outlined above) and then leaving step 5 for the manual part....... I guess I'm just not seeing any benefit or advantage with one way over the other if still a tech has to put manual touches on it...

[Nick]

OK, I now have a "clientID changed by commandline" install running on my laptop.

I'll take the XL (thanks to http://reddit.com/r/keto)

Good work.

edit: looks like the newinstall email may not have sent. investigating

Hmm.... the new install email wasn't something I just added, but it may have not been working before - I'll get a look at it if you can confirm now whether it worked or not.

For your client ID switching test, did you use the /set /clientid= switch to use an existing client ID, or did you use the /newclientid= parameter to create a new one? If you used the /newclientid, can you verify it created this in your mgmt console? if you didn't use /newclientid, time to do more testing!

[csc]

I guess what I don't understand Ray is how you can assign a unique client ID to each install without putting your hands on it personally. Maybe I'm being dense right now, but how can you assign a unique ID either during audit phase or during an oobe phase? Unless you are generating them named with sequential numbering or something... but then how to tell who has what?

I see you say originally that in step 2 your tech is putting in the info manually -- well that won't work obviously if you don't know who is going to buy your PCs yet. On the other hand if your example doesn't really apply to what you need to do, and you do have a tech in step 2 putting personal touches on the PC for the client during audit phase, then I don't understand why you're trying to automate step 5 when you aren't going to automate step 2? what would the difference be in doing it vice versa like I suggested, automating step 2 (as I outlined above) and then leaving step 5 for the manual part....... I guess I'm just not seeing any benefit or advantage with one way over the other if still a tech has to put manual touches on it...

You make a few good points. Step 2 is not supposed to be automated, because it is done by a technician. Step 2 is pre-recovery image. I would like to make dSupportSuite part of that recovery image, so it will be manually entered in step 2 while the computer is still within the computer shop. Step 5 is an automated process that may occur more than once (if the customer uses the recovery partition). Step 5 needs to be automated, because it will occur in the field when I am not there. Step 2 I will be there for. Also, if it's just a registry entry, I assume I can add name, phone and email after the fact by creating a "reg" file and associating it with their identity in the dCloud. So heres how it would work beginning to end:

I would PXE boot the computer, install the OS over the network, boot to Audit Mode, do my Ninite and updates (ect) then wait for the technician. The technician will run an Info Report with d7III and upload it to the FTP server. Using PC Repair Tracker I'll assign a unique Client ID to the hardware, and set it in my PC Repair Tracker as "Ready for Sale". This unique number is the same number that I would use for the dSupportSuite client ID. Name, Phone and Email will be blank (because I likely don't know that information yet). The computer will be finalized and the recovery partition created, and then it will be placed on the shelf. When the customer buys it, the machine will say "Please wait while your computer turns on the first time" and then it will ask for Username, Password, WiFi Password, ect. Once the user logs in for the first time, I would like dSupportSuite to create the dCloud folder for it (not until then!) and I will know to update their configuration to include a reg file that contains their Name, Phone and Email. If the customer uses the recovery partition, I would then have to re-apply this reg file.

[csc]

Perhaps it is best described this way:

What if dSupportSuite installed similar to this? The closer it can get to an OPK the better.
http://www.intelligentsystem.com/blog/h ... m-builders

What if it could tell that the Name, Phone and Email fields were empty and prompt for those fields if they are not found? So they would run on first execution.

[vmhs]

Now this is a good idea.

/installopk /defaultclientid=nonpayingcustomer


then on first run, it says, ooh. who am i? better ask.

This does mean that if they never do a manual run tho, that it will not ask for the info.

unless there is some sort of "on first boot, after everything else has run, run this" key that I dont know about...

[csc]

@vmhs - That's exactly what I'm reffering to, but I don't want to use "non-paying-customer". I want to assign it directly to a uniquely identifiable client ID, which becomes active after first boot. I'll use a reg file to specify name, email and phone but I would also like it to prompt for that information on first run if it is not found.

[vmhs]

but if you have 30 machines on the shelf, how do you know which one you are giving it to? unless for you the client id is more of an asset tag?

[csc]

Correct, it is a unique "Device ID" which is generated by my CRM and is an asset tag not a customer identity. For me "Client ID" seems best to be described as the identity of the client which connects to the server. Every machine is therefore a different client.