Fog status ?
-
fog is being developed, contact Tom Elliot and see where you can help him.
Also, you can’t get rid of the windows service as some of us need to use sysprep and the PC named need to be changed after the PC is online.
-
[quote=“VincentJ, post: 23644, member: 8935”]fog is being developed, contact Tom Elliot and see where you can help him.
Also, you can’t get rid of the windows service as some of us need to use sysprep and the PC named need to be changed after the PC is online.[/quote]
I don’t want get rid of the windows service. It’s nice. A problem of traduction undoubtedly. I m worried about this possibility
I use sysprep too. But a sysprep " neutral" who especially does not ask any questions. Then the customer fog undertakes to rename the machines and to integrate them into the domain. -
i removed the need for the windows service regarding name change domain join (as long as it’s a sysprepped image you’re using) so the only thing i use the windows service is to deploy a snapin/script that installs several pieces of software.
i don’t use the HOSTNAME_EARLY feature, i get fog/init.gz to change the sysprep.inf or unattend.xml after imaging(before it reboots) to match whatever is set in fog for that particular machine so it sets hostname and ad all at once so when sysprep initially boots up the sysprep.inf or unattend.xml is already customized to match that machines details also meaning no need for reboots for domain join too.
-
All the ways lead to Rome. (As long as the job is made). You did pretty job. Congratulations.
However, (there is always) a question (the first of a long list) and one remark.
[U]1 the question: [/U]
Is the sysprep included in init.gz or should it be put on the machine?[U]2/The remark[/U]
In fog 0.32 with the customer fog, if the name is changed in a machine, on the server fog, this is made with the rebbot of the machine. With your method, l should be remade the image (longer).Moreover the customer uses already netdom to integrate the machines. This utility (netdom) offers many features.
Netdom renamecomputer, netdom remove, etc… which would have been interesting for an evolution of the product. The customer fog0.32 functioned already with netdom. Why give up it to go in a way giving less opportunities?But as one says criticism is easy and art is difficult. I do not want me which did not do anything to be a severe judge. I inform you , simply and sincerely, of an opinion of user.
-
answer to the question:
no - you build the image as normal (random computer name, set to join workgroup etc)
when you image a machine, fog will deploy that image (with the random computer name, set to join workgroup etc)
once the image is on the disk (before it boots into windows or anything) the init.gz will then mount the hard drive/partition, find sysprep file, open it, re-write it to include the hostname, and domain details, save the sysprep file and then let the machine carry on and reboot as normal.then sysprep will go through the process as it normally would but the sysprep file will have the correct hostname and the correct details to join domain.
-
As you state, all roads lead in (more or less) to the same place.
The FOG Service, in FOG 0.32 does NOT use netdom for rename or joining the system. Not to my knowledge at least. Maybe on Windows XP Pro this was the case, but I’m pretty sure it doesn’t do this on Windows 7.
Lee’s approach, basically, was to have an unattend.xml file for whatever situation necessary. He would (and correct me if I’m wrong) have a generic unattend.xml file that, after fog imaged, would be planted in the proper place on the partition. Then it would assign the name in the unattend file based on the hostname the system was registered as. The unattend did all the work then. It changed the hostname and joined to the domain. The two biggest reasons why people needed the FOG Client in the first place.
We’ve since learned how to change the hostname using registry keys as well, and that was being tested in FOG 0.32. It worked for Windows XP, but I don’t know how well it worked for Windows 7.
If your customer is already using netdom to rename the machines and join it to their domain, then there’s no need to change it.
Chuck’s reference to removing the FOG service due to the ability to change the name before the system is booting was just a poker question I believe. The intent, at least from how I’ve been developing the latest, is to keep the FOG Service there. I will have to learn C# and will eventually rework the code so it’s more fluid and gives more information, but it is not going to be given up, which I believe was your concern here.
As a matter of fact, I hope to keep the FOG Service and eventually make it better. While I may not understand C# yet, I assure you, in time I will make the FOG Service more dynamic and configurable. At least that’s my hope.
-
[quote=“Tom Elliott, post: 23655, member: 7271”]As you state, all roads lead in (more or less) to the same place.
The FOG Service, in FOG 0.32 does NOT use netdom for rename or joining the system. Not to my knowledge at least. Maybe on Windows XP Pro this was the case, but I’m pretty sure it doesn’t do this on Windows 7.
Lee’s approach, basically, was to have an unattend.xml file for whatever situation necessary. He would (and correct me if I’m wrong) have a generic unattend.xml file that, after fog imaged, would be planted in the proper place on the partition. Then it would assign the name in the unattend file based on the hostname the system was registered as. The unattend did all the work then. It changed the hostname and joined to the domain. The two biggest reasons why people needed the FOG Client in the first place.
We’ve since learned how to change the hostname using registry keys as well, and that was being tested in FOG 0.32. It worked for Windows XP, but I don’t know how well it worked for Windows 7.
If your customer is already using netdom to rename the machines and join it to their domain, then there’s no need to change it.
Chuck’s reference to removing the FOG service due to the ability to change the name before the system is booting was just a poker question I believe. The intent, at least from how I’ve been developing the latest, is to keep the FOG Service there. I will have to learn C# and will eventually rework the code so it’s more fluid and gives more information, but it is not going to be given up, which I believe was your concern here.
As a matter of fact, I hope to keep the FOG Service and eventually make it better. While I may not understand C# yet, I assure you, in time I will make the FOG Service more dynamic and configurable. At least that’s my hope.[/quote]
No netdom on the customer fog that then! But why did I think that?
With my discharge the reference to netdom is in ProgramFiles/fog/etc/bin/fog.ini on the customer. And to say that with each image I took great care to pose my netdom well and to show the good way. Moreover, without seeking too much on google one finds references on fog which encourage to place it, it thereof to same on the WIKI of fog, the option at summer given up in the course of road.
I tested with fog 0.32 kernel 3.8.8 customer fog on the machines. I removed netdom and indeed all occurs well for less XP customers and seven. I will work with that.
For the remark that I made on netdom, your answer is limpid and I adhere to it completely.
If one day I put myself at C++, perhaps I would reconsider the subject. And then one should not be too greedy, it is already a happiness which you provide a product such as fog. -
[quote=“Lee Rowlett, post: 23654, member: 28”]answer to the question:
no - you build the image as normal (random computer name, set to join workgroup etc)
when you image a machine, fog will deploy that image (with the random computer name, set to join workgroup etc)
once the image is on the disk (before it boots into windows or anything) the init.gz will then mount the hard drive/partition, find sysprep file, open it, re-write it to include the hostname, and domain details, save the sysprep file and then let the machine carry on and reboot as normal.then sysprep will go through the process as it normally would but the sysprep file will have the correct hostname and the correct details to join domain.[/quote]
I will test it. -
Oups… thank’s for the answer.
-
The registry hack works fine for 7, as far as I know. But it won’t help for sid/AD integration obviously
