Fog status ?
-
Hello, I am sorry I do not speak English, and I do not write it either… Reassure you I manage to survive without. This is thus a text outcome(exit) of a French-English translator. Being in the habit of reading texts translated the other way I know that the syntax is rough, but well I hope that you will understand all the same what I say (or rather what I write).
First of all and it is very normal thank you for the excellent work which you supply.
About the features of the customer fog I wanted to intervene on this point:
[url]http://fogproject.org/forum/threads/fog-status.4515/[/url]
[B][I][COLOR=black][FONT=Arial]Then I would like to change things up a bit. I would like to form two or three teams, one that would maintain the UI, and at minimum another to maintain the Linux init image and kernel. I would like to then either discontinue the Windows service (since we can change the hostname [U]via the init image now[/U]) or move it to another team.[/FONT][/COLOR][/I][/B]
[FONT=Times New Roman]Without presumed the used language of programming, I wanted to draw your attention on the fact that:[/FONT]
[FONT=Times New Roman][/FONT][FONT=Times New Roman]The specificity of fog is to supply to the user a way(means) “simple” to arrive at an installation " zero touch ".[/FONT]
[FONT=Times New Roman]
It is this who(which) made me prefer fog to the other solutions. (I read 4 000 000 of the pages on MDT without finding really how to equal fog 0.32. The zero touches, they speak about it all the time, but they never say how we make).
Exactly with fog the " zero touches ", it is easy!. After the cloning, the customer takes the relay. He renames machines and, in the moose(run-up) he JOINS them into the domain. If in more we place them directly in the good one OU, the strategies of group are applied as soon as the machine is ready. BRILLIANT![/FONT]
[FONT=Times New Roman]The fact of envisaging "[/FONT][B][I][COLOR=black][FONT=Arial] change the hostname [U]via the init image "[/U][/FONT][/COLOR][/I][/B][FONT=Times New Roman], Leads(Drives) me to ask me if the integration in the domain would still be there. Without taking into account the integration in a domain Windows would make, I believe, lose a lot of interest in your product. [/FONT][FONT=Times New Roman]
It is true that some of the features of the customer fog are ineffective. We can also take place of some with a good management of the images.
However for the working groups(without domain) the [B]management of printers[/B] and [B]the snapin[/B] present certain interest.Thank you of the attention that you carried me, if you read this up to the end.[/FONT]
-
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
