Not really a NUC specific question, we have had this working perfectly on NUCs under Linux, and we're getting there on the NUC7i5/NUC7i7 units under windows, too.
We're embedding NUC motherboards in units for film- sets, and the units don't even have a power on/off button... Actually there are no buttons at all.
Basically they turns on when power is present, and closes when power is off, and in-between they act like the small robots they are...
In linux we made this a dead robust solution. Had them on set for 18 months and they always worked.
There is no way to attach a screen to the unit (HDMI/display port is not exposed), they are remotely serviced and basically you interface with the units through web-apps.
we also really want to avoid the user hooking up a screen, a keyboard and a mouse and start playing solitaire on them. To the user, this is just a smart IoT device.
We're still early in the Windows testing, compared to our linux experiences, but any tips and tricks are advised. But BSOD at startup is a bugger if/when it happens, though it seems pulling the plug and re-plugging it solves most BSOD we have lately. (We have done a bit of config)
But what are your advices for this kind of setup. I am pretty certain we're not the only ones using windows like this.
We have to use Pro 64, not IoT
Thank you for contacting the Intel community.
In this case for the motherboard to power on when receive power this needs to be configured in the BIOS under the power options; you can set the power state to power on.
About your set up we will need to wait if somebody can jump on the thread and give you some advice because Intel has not validated this configuration so there is no advice we can provide. To be honest I'm not familiar with this configuration, do you have the latest BIOS version install for the motherboard? I understand that you cannot connect any monitor and that you manage the unit remotely but I'm just asking.
I'm sorry if my help here with this configuration is not much of a help but hopefully somebody else who is more familiar with this set up can help here.
So let me get this straight: you have a system, running Windows, that is shut off by pulling the plug. No power button, no nothing. What do I think of this? I think you will eventually see the Windows system drive become corrupted (and, frankly, I am amazed that you haven't seen the Linux system drive become corrupted as well). Plain and simple, Windows needs an orderly shutdown. Now, if you had a big capacitor that could provide the NUC with enough power to complete its shutdown and you had a way to signal to Windows (power button press would do) that a shutdown was necessary, it would be ok. But just pulling the plug? Um, no.
I hope that there is more to this than you have described...
There are a ton of devices running Linux under these conditions, and we had absolute no problems (after initial tweaking) for 18 months on several devices running for months, and it shouldn't be that surprising.
My Cameras (for years) have been Linux computers, and people made windows bades cameras more than 10 years ago.
This is pretty normal. It's an "embedded computer device", boots in seconds.
It's absolutely no point in putting a power button on a device you know will not be turned down that way at least half of the times, and which basically needs to run as soon as it gets power.
Again... I am pretty confident we are not breaking any new ground here As I have been using windows and Linux devices working this way for more than 10 years.
What I know, is that we spent a bit of time setting up Linux right, and I expect we will do the same for windows.
We have done a few things, and it's getting pretty robust. But we have still not tested this to the same degree, and I am looking for tips.
(It's possible, but expensive and has a size/weight punishment) to put in a small "shutdown UPS" in there, but this is going on handheld camera-rigs already in the 10-25 Kgs range, so every ounce of weight counts.
Frankly, we would have preferred to use something like the ComputeStick, but that platform is still not mature enough for this kind of abuse for a number of reasons, we have seen after 3 months of tests.
But basically: I know we're not inventing the wheel here. I am just curious how others doing this have set up soft- and hardware.
Yes, as we have done this for a few years with prototypes, we have the BIOS set up for this behavior.
We know we cannot access the BIOS after assembly,, and the BIOS is updated to the latest. And that's of course a risk, but we roll these out slowly, on 10's at the time, and all end up with a "safe" BIOS/System combo that will be deployed.
In this configuration, the "normal" is that you do not want to update anything on the system side after release.
To the end user, this in not "a computer", but a thing that you put on your camera like any other camera device. Most of those runs some variant of Linux anyway....
The NUC has been a pretty robust platform amongst all those we have tried. But it wasn't until the gen7 it became a usable one.
Thanks for the replies
Yes, I agree; there are ways to configure Linux for embedded usage. Windows is another animal, however. I will be interested to get an update from you once you've gotten a lot further along in your testing.
I somewhat agree with the freezing of the BIOS and software. Where I might question this policy is with respect to security. There is the possibility of security flaws being found that are pertinent to the features you utilize and these could be in the Windows O/S, add-on software (like that for remote access) or even in the BIOS. If you do support an update model and include the BIOS in this, I recommend that you stay away from the Express BIOS Update (EBU) packages, which initiate BIOS updates from within Windows. I no longer completely trust these packages; while I have never seen it occur myself, there have been reports of problems occurring as a result of the use of this update method...
I also agree with your assertions regarding the Compute Sticks. The hardware is very fragile and the BIOS is not robust.
The units are now out and doing their work and we are about to produce the next batch.
We have no heat issues and after a bit of fighting with the system, we have had zero file-system issues.
It's becoming the stable platform we envisioned.
Sorry for the bad video-quality.
http://quine.no/ You can read more about the project here: