>"Control the general Windows shutdown" - speaking as a sysadmin, this is not a good idea.
Yes, I know that. But, higher administration has requested to turn those robots into services and they knew some of them are doing some very robust procedures that may take several minutes and such. So, we have services. And, while this is not within the average usage of a service, it is what I have to deal with.
>First, if your processing depends on other physical or virtual machines, and they become unavailable during a general shutdown then your processing will likely fail.
That is why OnCustomCommand() event and reflection come into the game.
>Second, if I need to shut down your server and/or the environment I have a good reason to do so. If one server refuses to shut down for minutes at a time, I will assume it's hung and I *will* kill it - in Hyper-V Manager, press and hold the power button for ACPI shutdown, pull the power cord - whatever it takes. You will get blamed for any corruption that happens in those circumstances.
No problem there, as I said, this is a controlled environment and sign off procedures (deployment type) applies when this is the case. So, we are not talking about a user PC here. This is a server that is likely to get rebooted about 3 to 4 times a year, well prepared (a few days ahead with everyone involved) and such.
>To keep your sysadmin on your side you'd need to do something like this:
They are on my side and they like it that we could automate our services like that as right now, they depend on us for shutting them down from an interface where we would like to automate that part.
>1. Give her accurate documentation about your job(s) and the time(s) when they are likely to run, and their estimated durations. She can then add this to her checklist of things to watch for prior to doing shutdowns
Not possible, the access to this remote management of those services are done by one team not the same doing the shutdown.
>2. Give her an interface where she can view the status of your service(s). It should show:
As per above points, this is related to various security levels which vary from one team to another.
>- If a job is currently running. If one is running, it should have some kind of accurate progress indicator - estimated time remaining, number of files left to process etc. This progress indicator should either update itself frequently (sysadmins are impatient) or offer a "Refresh" button so she can manually refresh it on demand
Yes, we have all that but for one specific team. The other team does not have the access and is only there to do the reboot.
>- If a job is not running there should be a capability to stop or hold the service's schedule. This is to prevent a scheduled job from starting say, 2 minutes from now, when shutdown of other dependencies in the environment may already be under way
>If you put something like that in place the sysadmin can plan ahead and schedule XX minutes of possible extra shutdown time, or try to avoid times when your services may be doing heavy processing. With a progress indicator she can see that your services are not hung and get an idea of when they will finish. From the interface she can stop or hold your service(s) so she doesn't have to worry about them trying to start up while everything else is being shut down.
Yes, good idea but not practical in our context. The payload is too much. So, I cannot have the 40 services stopped for about two hours until they do their job. This would immediately generate support calls. Yes, we have a window for such deployment related procedures. But, still, when it happens, the amount of times a service has to be stopped has to be for just the time necessary to do the restart. As we cannot control when exactly they will do it, we have to make sure the services continue to run until the time comes. And, presently, when it is time, they have to rely on us to do this operation.
>As a side note, depending on the exact environment effective shutdowns or loss of service can be more frequent than you might expect. For example, in a Hyper-V environment, if Windows Server Backup is used to back up VMs, those VMs are suspended during the backup. Other backup products can do so-called "live" backup without suspending the VMs. You might want to check with the sysadmin which type of backup is being used, and either schedule your jobs, or the backups so VMs you need don't get suspended unexpectedly.
This is all ok. If I can get this OnCustomCommand() to react with reflection, this would not cause any problem. Because, I will have a priority on my services to stop first and then, when all stopped, Windows will proceed with the shutdown event and will close the rest in one shot, thus a few seconds as per my actual tests (about 40 reboots so far). So, this new approach, and basically the only one that could work to answer our request, is as per the recent message I posted to move higher in the chain of shutdown sequence, thus at the pre shutdown event.
