@wayne-workman big multi-floor offices where the infrastructure is a scope per floor

Head Office:
ground floor - 192.168.0.0/24
first floor - 192.168.1.0/24
second floor - 192.168.2.0/24
third floor - 192.168.3.0/24
fourth floor - 192.168.4.0/24

and so on… and only requires one storage node/Location to cater for the imaging demand.

otherwise you’d have to do Location per CIDR…obviously this would be few and fair between but it’s worth considering…

also another scenario would be

Location A:
Mobile Devices: 192.168.10.0/24
Desktop Devices: 192.168.11.0/24

yeah this was an improvement me and tom discussed several times in the past to improve the location plugin and remove the need for “manual” location selection but was going to save the implementation for FOG2.

However, i’d welcome the enhancement - unfortunately i don’t have anytime at the moment due to work/personal commitments to dedicate to it but as Seb said, would be fairly easy to implement.

i’d recommend making sure we implement being able to add multiple CIDR addresses to a location.

this would certainly remove the “User Error” in choosing incorrect locations or forgetting to change location when kits moved killing the WAN links and contradicting the whole reason for location plugin… not that, that ever happens of course rolls eyes lol

04_bzimage

03_bzimage

02_bzimage

@sebastian-roth as predicted 01_bzImage hangs on Early in __setup_efi_pci64… 1 2 3 4 5

testing 02_bzImage now…

@wayne-workman forum is deciding to fight with me… lol, added link to higher res

Opening thread on debugging uefi pxe issues on this device… latest test 05_ipxe:

https://drive.google.com/open?id=1K6UJ0ybn5PDcC_KSCkgpEwfZOs2lLcCl

@Sebastian-Roth

Lenovo IdeaPad Miix 310 - 05_ipxe.efi

check BIOS for multiple windows boot manager entries this could potentially be adding to the issue?
for example:

you will be able to do it within the Access Control Plugin (haven’t looked at it since it’s been rewritten) - if not you can certainly achieve it with a simple hook.

public function MenuData($arguments) {
    if (!in_array($this->node,(array)self::$pluginsinstalled)) return;
    if (!self::$FOGUser->isValid()) return;
    $this->linksToFilter = array('accesscontrol', 'ldap');
    foreach((array)$this->linksToFilter AS $i => &$link)
    unset($arguments['main'][$link]);
    unset($link);
    }

@freak
checkin and obtain taskid

http://FOGSERVER/fog/service/snapins.checkin.php?mac=MACADDRESS

then to update status:
http://FOGSERVER/fog/service/snapins.file.php?mac=MACADDRESS&taskid=TASKID&stateid=STATEID

so like tom pointed out not perfect for percentage or showing a progress bar however dependant on what you’re doing you can get it to display at what stage your snapin is at…

i have one snapin install several software packages dependant on several variations however with the task state, the engineers know at what it is at… this can be easily achieved with http calls within ur script, you will just need to obtain mac and taskid and then send stateid and hook to display custom states.

not quite sure if this is what you’re looking for?

@george1421 I’m pretty sure from when we use to have HP’s that the first partition was a system recovery partition which when browsing contained snapshot of OS files so would confirm your theory!.. Slightly off topic but line 27 in fog.postdownload got a typo, ntf should be ntfs

@Raj-G under <settings pass=“specialize”>

<component name=“Microsoft-Windows-UnattendedJoin” processorArchitecture=“amd64” publicKeyToken=“31bf3856ad364e35” language=“neutral” versionScope=“nonSxS” xmlns:wcm=“http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
<Identification>
<JoinWorkgroup>Workgroup</JoinWorkgroup>
<Credentials>
<Password></Password>
<Username></Username>
</Credentials>
<JoinDomain></JoinDomain>
<MachineObjectOU></MachineObjectOU>
</Identification>
</component>

the above is for 64-bit… if you’re ever unsure use WAIK to generate your unattend file for you if you don’t feel comfortable doing it manually

Very nice addition! well done!

@Bob-Henderson DevicePath Registry wont work with Windows 10 - im sure its mentioned in links george has already posted

in the interim, you could always setup rsync until toms worked his magic :-)…

you definitely don’t want to put all your drivers onto image not only would it be needlessly bloated in size, like you’ve pointed out - you’d do well to get them all installed and working

just repeating what George has said below, that is the cleanest and most reliable method below - just heads up, watch out for windows 10 driver changes (when you come to do windows 10)

don’t be put off by the postscripts method, it’s easier than it looks - just take your time reading the write ups - @george1421 has done some pretty clear and indepth ones in all honesty and we can always assist you if you get stuck

why would you want to blindly apply windows updates post image anyway? surely you should be going through some form of testing at least…?

maybe that varies in different environments and we have to air on the side of caution because if our systems go down/stop working people start dying… lol

@rmurra81 said in Do windows update on uploded image stored on fog server:

It would be very difficult to inject Windows updates into an image, but what this thread should be talking about is to spin up a VM with those image files. This would allow you to run updates, install programs, maintenance, etc. It seems stupid to me that the conversation didn’t go there. Why would you spend all your resources updating this FOG server software for it only to do windows update? Tom Elliott, that is a waste of time. Deploying an image to a PC and then running updates just to capture it. Just setup WDS and run a VM. This feature already exists and it seems like it wouldn’t be that difficult. Maybe some button to deploy to a VM within the FOG Server.

that’s how you should be building your images… build on VM, snapshot/create checkpoint before sysprep/capture… when you need to apply windows updates to your “image”, revert vm to snapshot/checkpoint - apply windows updates, snapshot again before sysprep/capture etc etc etc…

you’ll have a cleaner image building on VM and you avoid rearm restriction as theoretically your image only ever gets sysprepped once (as you revert to unsysprepped state before applying changes/update)

so that’s not a feature needed in FOG that’s a learning curve or a “suggestion” if you’d like that we need to teach FOG administrators…

“Maybe some button to deploy to a VM within the FOG Server”… that’s what the deploy task button is for unless i’ve been up far too long and i’m reading that wrong, you clearly don’t understand the architecture behind virtualisation if you think that could be implemented so easily. it would kill most environments just trying to implement that and most FOG Servers are being hosted on a VM already so then you’re talking about nested VMs and that’s just the tip of the iceburg on that head ache… can of worms springs to mind just to do something you can already easily and quickly do a thousand different ways as wayne and tom pointed out a few below

Edit: Just read the other thread you’re discussing this - if you mean deploy the image to a vm, you can do that like you would a physical machine, register the VM within FOG and deploy image, do your updates and maintenance etc etc and then capture, don’t think i fully understand your VM Feature request, maybe you could explain better?