Also you could try to specify some settings in your unattend.xml sysprep answer file:
<PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
<DoNotCleanUpNonPresentDevices>true</DoNotCleanUpNonPresentDevices>
Also you could try to specify some settings in your unattend.xml sysprep answer file:
<PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
<DoNotCleanUpNonPresentDevices>true</DoNotCleanUpNonPresentDevices>
And what about the new way of activating Windows 8? Apparently new pc’s don’t come with a license key at the side of the case, Microsoft is pulling the OEM-key from the BIOS. How does Fog 0.33 handles this?
More information can be found here: [url]http://answers.microsoft.com/en-us/windows/forum/windows_8-windows_install/where-do-i-find-the-windows-8-product-key-when-it/d4c5c0c1-825d-47f2-9bed-d9625c7e68ff[/url]
My guess is it has nothing to do with fog. It has to do with your unattend.xml file.
You have to double check it against some online tutorials.
Also, what you’re telling doesn’t add up:
By default the computer is running sysprep according to your unattend.xml and AFTER that fog is renaming the computer and is joining the domain. You’re telling the computer is joining the domain and after that sysprep is running?
That error you’re having has to do with the rights. You have to give the proper rights to the user/group fog is using to write to the image directory.
This is great news, but i’m a little sceptic.
We’ve had many problems while running fog .0.29 and not using sysprep.
The cloned computers had the same CMID and the KMS server didn’t recognize them as individuals.
Because of that the license count didn’t reach 25, which causes the cloned computers to deactivate.
So i’m curious, what is it the fog service does exactly to change the CMID?
And since which version of fog has this been implemented?
Kevin, we’ve been running that kernel (1037) since feb 7th only for the 780’s and the problem seems to be solved!
I’m not sure, sorry… I allmost think you should create an unattend.xml for each pc with a unique licence key…
I would use one vlan for computers, one for wireless networks, one for IP phones…
Just place one dhcp server in each of the vlans?
You could also use VLANS, as a workaround?
I guess thats also something you should want to do, setting up your phones on a seperate VLAN…
using the 390’s here as well, without problems… not sure if we have the realteks as well, but with fog 0.32 (no kernel changes) and using the chainloading fix we’re not having any problems at all?
9,200 computers? Realy cool!
I’m using FOG on a dedicated Dell 780, 4GB RAM on a 1GB network.
Currently imaging around 200-250 computers. Deployment runs very very fast, it’s running at full network speed without problems and while deploying it’s just using a few 100 mb’s of RAM.
Also using the fog user tracker to check how many users are login in/out and checking where pc’s are rarely being used so we can move them to other locations.
This is the right place to thank you guys, you’re realy doing a great job!
You’re helping many many people all around the globe! Looking forward to 0.33!
try using kernel id 1037, only for your 780 hosts.
Works like a charm on my 780’s over here
I would highly recommend using the unattend.xml, if you don’t you have to go through the “welcome to windows” wizard after deploying images…
using the default linux commands (asuming the apache user is set to default www-data)…
[CODE]chown www-data:www-data www[/CODE]
How many characters is your new and old hostname…
There is a limitation to the number of characters, 11 or 13 max if i remember correctly.
Hi guys,
Major breakthrough here for the problem with the Dell Optiplex 780.
While using the kernel with id 1037 the problem seems to disappear.
I’ve set the kernel setting per host on all my 780’s so that it doesn’t affect other pc’s.
Problem solved (for now?)!
[S]I seem to have found the problem: a BIOS setting combinated with the new fog version causes the problem.[/S]
[S]SATA operation was set to “raid on”. Switching this option to any other option seems to correct the problem.[/S]
Unfortunately, that doesn’t do it. Sometimes it reboots, and sometimes it doesn’t…
I doubt it’s a BIOS related problem, because while using FOG 0.29 the problem didn’t occur.
I updated to 0.32 yesterday, that’s when the problem with the Optiplex 780 started…
[S]Will try to update to the latest BIOS though, just to be sure…[/S]
edit: updated the BIOS to version A12 (latest available BIOS) but the problem still occurs