@Almeida The fog-client service runs as SYSTEM user by default. Not sure if that has enough access rights to run bcdedit. Search the forum for “psexec” to find a topic explaining how to use PsExec to test-run commands under the SYSTEM user account.
@jacyjacy77 While I realize this won’t help you, I do find this entreging from a secops perspective. So the bad actors were able to compromise the cloud hosting provider, compromise the command and control function to reset the devices. This is just a postmortum question, but can you manage these devices without a cloud account? Is there local management features? If you can manage them locally, the simple security fix is to assign a static IP address and subnet mask to this device but don’t set a gateway address. The device will not know how to leave your local network. There will be no chance for it to access the cloud controller or receive external commands. That way the device should remain functionally locally and not have the risk of external compromise. Firmware updates haven’t been issued since 2015 so unless WD fix this hole with a firmware update that probably the easiest and most assured way to keep using this device if you are so inclined.
Pensez à écrire en anglais sur ce forum (en attendant un sous-forum français). Deepl est votre ami pour la traduction https://www.deepl.com/translator
Pour déployer un serveur Windows, je mettrai Windows Other au niveau de l’image.
Traduction Deepl :
Think of writing in English on this forum (while waiting for a French sub-forum). Deepl is your friend for translation https://www.deepl.com/translator
To deploy a Windows server, I will put Windows Other at the image level.
I’ve had ipxe.efi work 99% of the time, but there’s some models that only snp.efi and snponly.efi work on.
The issue is that those models having an issue with ipxe.efi use the same vendor class than the others and can’t be distinguished from the by vendor class identifier.
I am not very good with Windows DHCP server but in generel you’d setup a particular rule/policy for problematic clients using their MAC address to distinguish those from other machines.
This tells me that it’s deploying Disk1 to /dev/sda AND /dev/nvme0n1
I don’t think this is the case! It’s just the partition layout that was deployed to /dev/nvme0n1 on an earlier run and it’s still like that because for some reason it only deploys one disk right now.
Please check your image and host settings again. Is the image set to All Disks? Also make sure Host Primary Disk is not set for the host you deploy to.
@george1421 My apologies for the repeated posting. Just wanted to follow up to say that the FOG Client DID join my test machine to the domain as desired this morning. Not sure what the difference was (other than that the laptop had not previously had a power cord plugged in), but it looks like everything is behaving as I had hoped it would. Thank you again for your time and effort to help me out.
@Bristow-0 As well question arises if both the workstation and VM are in the same mode - legacy BIOS or UEFI. With ProxMox you use KVM for this I suppose.
@sebastian-roth Sorry if this is a dumb question but I’m pretty new to all of this, I am trying to PXE boot now but its showing no boot file name received. Thanks!
@tom-elliotthello,
Excuse me for the long time to do the tests, I don’t have much at the moment for this project.
Here is the photo of the debug (the error message comes up over and over again countless times).
Wow, something I would not have thought of right away! Good you found why it fails!
No there are no proxy configuration settings in fog-client. We use simple C# .NET WebClient calls. That seams to be using your system proxy settings. Can you set your systemwide proxy settings to not use the proxy server if connecting to your FOG server?
@arowana Does your remote site have a server where you can preposition these dependencies files? Remember for windows the script or installer runs as a windows user. The fog client runs these snapins as SYSTEM which has admin rights on the local computer where the snapin is being installed. Your install script can map a drive to a windows file share and copy the files over smb to the target computer. That would be the easiest. If the files were stored at the remote site then it would not impact your metered connection rates. If you used a powershell script to install your application you can use a function similar to curl or wget to download the file from the internet using scripting. You might be able to use FTP too, but I have never tried. You don’t need to specifically download from the FOG server, but you can. If you wanted to download from the FOG server, I would setup a new user on the FOG server that has very limited rights, maybe to read only from the source directory and that is all. I would not use the FOG ftp user because that has more authority than what is needed here.
If the renaming/domain join occurs AFTER the final restart I will need to run a powershell script to install our AntiVirus software and also add a domain user account to the Remote Desktop Users group –
You might want to consider deploying this action with a snapin. Snapins will run after all of the other imaging actions are complete.
I am still not sure if this is something the fog-client is doing wrong (we just use the slmgr.vbs calls that worked for a long time) or if it’s Windows preventing it from happening.
@nfiglar Typically you would add the command to add the computer to azure ad in the setupcomplete.cmd batch file or in a first run command in the unattend.xml script. At the very least you could create a snapin to deploy a package that joins the target computer to azure AD. dsregcmd /join
