Best posts made by george1421

I didn’t forget about this project (hack), I’ve been tied up with a few commitments for the last few days so I haven’t been able to push to far. I’m going to post what I have so far (just the concept) so I don’t forget what has been done so far.

I’ve looked into how I can best augment what is in place to allow some kind of persistence so newly added hosts will be updated with the values I’ve defined in the host template.

I’ve looked through the db structure for FOG and identified several tables that could help me in my quest. These tables are (hosts, groupMembers, printerAssoc, snapinAssoc, moduleStatusByHost). My approach will a specific database event that is triggered when a record is added to the groupMembers table. This trigger will fire after a new record is added to this table. The trigger will check to see if the group which is associated to the host, has a matching template (also stored in the hosts table). The trigger will attempt to find a hostname that matches the group name (exactly). If it finds this template, it will copy the contents of certain fields from the template record to the host record. After that update is done it will copy the snapins, printers, and modules from the matching host template to the host. In theory this “should work”. If a new group association is added and there is no matching host template then nothing is updated. The only down side I can see with this approach is if you have an established host with custom settings and you assign that host to a group where there is an associated host template, existing values will be overwritten with template values.

@Sebastian-Roth said:

Then run dmesg | grep -i eth and lspci (full output of Ethernet controller so we might see if it is really using tg3). Thanks!

I’m sure a few commands hard coded into a menu selection like this would be handy to have, especially if they were in the FOG advanced menu so a user could just run them upon request of a a dev.

This unattend.xml should get your started. It contains the major sections you can edit with WAIK. This is for a x64 bit windows install.

Hint: You could insert custom fields identifiers in this xml file and then replace them with a fog post install script. That could make the unattend.xml file generic and specifically targeted to the deployment environment using a bit more complex fog post install script.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" 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">
            <ComputerName>X64DEFAULT</ComputerName>
            <CopyProfile>true</CopyProfile>
            <RegisteredOrganization>Domain Corporation</RegisteredOrganization>
            <RegisteredOwner>Domain Corporation</RegisteredOwner>
            <TimeZone>Central Standard Time</TimeZone>
        </component>
        <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>
                <Credentials>
                    <Domain>domain.com</Domain>
                    <Username>LittleJimBob</Username>
                    <Password>Not-a-Secret-Password-For-Me</Password>
                </Credentials>
                <JoinDomain>domain.com</JoinDomain>
                <MachineObjectOU>change_me_in_postinstall</MachineObjectOU>
            </Identification>
        </component>
    </settings>
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" 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">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>3</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>
            <RegisteredOrganization>Domain Corporation</RegisteredOrganization>
            <RegisteredOwner>Domain Corporation</RegisteredOwner>
            <TimeZone>Central Standard Time</TimeZone>
            <OEMInformation>
                <Logo>C:\Windows\DomainLogo.bmp</Logo>
                <Manufacturer>Domain Corporation</Manufacturer>
                <Model>TurboZip</Model>
                <SupportHours>24 x 7 x 363</SupportHours>
                <SupportURL>http://helpdesk.domain.com</SupportURL>
                <SupportPhone>+1 666 1234567</SupportPhone>
            </OEMInformation>
            <UserAccounts>
                <DomainAccounts>
                    <DomainAccountList wcm:action="add">
                        <DomainAccount wcm:action="add">
                            <Group>Administrators</Group>
                            <Name>BigJimBob</Name>
                        </DomainAccount>
                        <Domain>domain.com</Domain>
                    </DomainAccountList>
                </DomainAccounts>
            </UserAccounts>
            <AutoLogon>
                <Password>
                    <Value>No-Secret-Password-For-You.Sorry</Value>
                    <PlainText>true</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <Username>BigJimBob</Username>
                <LogonCount>1</LogonCount>
                <Domain>domain.com</Domain>
            </AutoLogon>
            <FirstLogonCommands>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>shutdown.exe -r -t 30 /c "The computer will reboot in 30 seconds"</CommandLine>
                    <Description>Reboot at end</Description>
                    <Order>2</Order>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <Order>1</Order>
                    <RequiresUserInput>false</RequiresUserInput>
                    <CommandLine>cscript /B C:\windows\system32\_slmgr.vbs /ato</CommandLine>
                    <Description>Activate Windows</Description>
                </SynchronousCommand>
            </FirstLogonCommands>
        </component>
        <component name="Microsoft-Windows-International-Core" 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">
            <InputLocale>en_us</InputLocale>
            <SystemLocale>en_us</SystemLocale>
            <UILanguage>en_us</UILanguage>
            <UserLocale>en_us</UserLocale>
        </component>
    </settings>
    <settings pass="generalize">
        <component name="Microsoft-Windows-PnpSysprep" 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">
            <PersistAllDeviceInstalls>false</PersistAllDeviceInstalls>
        </component>
    </settings>
</unattend>

@mm-Ekimia I can honestly say, in 5 minutes I can setup a computer on the bench, pxe boot a target computer, deploy an image, power it off and setup the next computer for imaging (I may have fudged the time just a minute or two, but pxe booting into FOS is about 20 seconds at the most). My total push time is about 3.5 minutes for a 10GB reference image.

Understand I’m using FOG 1.3.0RC14 for imaging and the developers have made huge improvements in speed and new hardware support since the 1.2.0 days. I can’t understand the 5 minute to partclone start. That IS almost my entire unitcast image deployment process.

@george1421 Well after fine tuning the sql query for the trigger I tested it on my dev box this morning. It worked exactly as advertised. When you associate a device with a group name, where there is a host (template) with the same exact name, the contents of the host (template) will be copied to the device that was just associated with that group. If you associate a host with a group that has no matching host (template) nothing is changed for that associated host.

There were a few caveats that I found, more like rules than caveats.

1. Your group name must conform to the rules set out for hosts. In that your Group name may not contain spaces or more than 15 characters. The edit box for the host restricts these the group name does not.
2. For every host template you must define a unique mac address, duplicates are not allowed. So for my first host template I entered 00:00:00:00:00:01 and for the second 00:00:00:00:00:02 and so on.
3. When you make a host group association all of the fields (even empty ones) will be cloned to the associated host. All existing setting will be overwritten on the association.
4. After you have made the host group association, if you make a change to the host template those new settings are not updated on all hosts associated what that group (but you can still do this via the normal group update function)
5. Do NOT make the host template a member of the group you are trying to make persistent. I could see a loop being created by the trigger trying to reference a template that it is currently trying to update.

While I say this works, I have not attempted this (hack) on our production server just yet. I feel confident that it will work without issue. Since we are not making group associations every day (as you would if you added new hosts every day) I don’t see any performance issues.

While this is probably injecting noise into this thread. We will typically create our reference image on a VM with 1 vCPU and 40GB hard drive. With fog we will use a single disk non resizeable (only because 1.2.0 didn’t work to good with resizeable disks in our environment.) but anyway, in the setupcomplete.cmd file we would run a script to expand the logical disk to the size of the physical disk. It worked well. In this setup we capture the image without the drivers for the final target computer so the image comes in at about 5GB on disk for a thin Win 7 image and about 15GB for a fat win7 image with office and other apps. Then just after the images are laid down on the target computer we use the fog post install scripts to inject the right driver pack from the fog server to the target computer. This saves us about 15GB in space on the target computer that we don’t have to upload (once) and download for each OSD. Also as new hardware is released we just need to update the drivers on the fog server, there is no reason to recapture the image.

@RobTitian16 Be aware that Microsoft OEM licenses don’t support/provide imaging. Just be aware of licensing of you use customized OEM images.

But I would look at this section to run custom commands on first login. Just make sure the first login section is a user that has local admin rights.

                <SynchronousCommand wcm:action="add">
                    <CommandLine>shutdown.exe -r -t 30 /c "The computer will reboot in 30 seconds"</CommandLine>
                    <Description>Reboot at end</Description>
                    <Order>2</Order>
                </SynchronousCommand>

In your environment, based on what you posted, do you need to sysprep, no. As for best practices, do you want to sysprep yes.

In my environment we have a single image for all platforms so we do sysprep the base image and then inject the drivers using post install scripts. But we also have KMS, WSUS, and other software that relies on a unique system suid.

@Wayne-Workman said:

Any way to add rules so it doesn’t apply if the template is a member of the group?

Or…

Should we force the template to be a member of the group and just disallow settings applying to the template… ???

Thinking about it, we probably could update the check for a null template id to also ensure the @myTemplateID variable does not match the @myHostID. If it does then not execute the update. [edit] wow there was to many double negatives in that statement. I should say its possible if we update the conditional if check[/edit] That should do it.

I can confirm for sure that the o780 works flawlessly with FOG with dhcp served by MS DHCP server.

@x23piracy While this isn’t FOG related, imaging rights are important to follow. If you want to survive an audit you should understand what you are allowed to do and can’t do.

Chris (from Microsoft) has posted 2 clear documents on what you can do with system imaging (from a MS perspective). This question comes up on Spiceworks almost daily.

https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

https://community.spiceworks.com/how_to/69219-reimaging-rights-how-they-apply-to-your-licensing

Take these documents as a clear explanation of the MS EULA.

It is true if you have a single VLK key, you can deploy any number of systems as long as the OEM key is licensed for the same OS as the VLK key. For example if you have a single VLK key for Windows 10 Pro. You may reimage any number of computers that came from the manufacturer with Windows 10 Pro already installed. You may not use the VLK key for Win 10 Pro to deploy Win 10 Pro to a computer that had Win 8.1 previously installed. That is a different license (version upgrade).

You may get a better response if you post this over on Spiceworks. There are people there that I’ve seen mention ClassicShell.

But I can tell you that most just deal with the new menu.

@networkguy Just a comment, if you use dhcp reservations you can define on a per client basis dhcp options. So while you are testing with this single client you can point to the new fog server and boot file. You can do this without breaking your current deployment environment.

Lets take a step back here.

You are doing a p2v migration. What hypervisor are you using? If you are using vmware there is a much easier path, unless you are doing an OS upgrade at the same time.

Before you sysprep’d the reference image did you remember to disable the FOG service? It should be set to auto start at the end of the setupcompleted.cmd file. That is the standard away.

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@cnkpadobi OK good your router at least supports the pxe booting options.

From here to see what is really going on, we need to get a pcap of the booting communications.

This is pretty simple since all of these devices are on the same subnet.

1. Install tcpdump on your FOG server.
2. Ensure that dnsmasq is not running on your fog server. If your dhcp server supports dhcp options 66 and 67 then dnsmasq is not needed at this time (possibly in a bit, but lets get this system pxe booting)
3. start the tcpdump program with the following options: tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
4. Now pxe boot the target computer to the error message
5. At the pxe target error press ctrl-C on tcpdump to exit the program.
6. YOU can either review this pcap file with wireshark, or you can post it here and we can review it for you. (if you don’t know what you are looking for, just post it here).

This pcap file will tell is the truth of what is going on in the wire.

I’ve written a kb article that describes a process that is based on the wiki you mentioned. This kb takes the install in a different direction. https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog My process doesn’t rely on vendor or hardware ID for proper installation. For Dell computers it works very will, some of the other vendors you have to do a little work to get the drivers into a sane state.

Also on that kb there is a link if you have dell hardware they place all of their driver cab file links on one page. http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

If you have Lenvov computers, good luck that site is a bad mess. HP is not too bad.

OK rereading your OP multiple times, the first thing you need to get settled is the database export / import. You need to get the settings and passwords into your new system. Without the database the rest of the bits are pointless.

If you are running fog 1.2.0 or a trunk release then there is a built in function to export the configuration from within the gui and then import into your new server. There is no need to use the spiceworks method. That is for the 0.3.x and older release.

GO into the Fog Configuration and select the Configuration Save option that will download the fog_backup.sql to your computer, then go to the new server and upload the settings.

@RobTitian16 Bitlocker???

Hint, don’t turn it on until after the image is on the target system. Save your self some pain. The VM doesn’t have a TPM chip probably.

@Sebastian-Roth I also saw that (missing next server) but I thought the “server host name” was the same. I guess I was wrong.

What Sebastian is taking about is in packet 7 and packet 9 the next server value is missing in the dhcp header, but the server host name IS set.

Packet 7

Packet 9

I agree with Sebastian’s recommendation to remove the dhcp options 66 and 67 from the watchguard box and then enable dnsmasq again on the FOG server. The DNSMasq service will provide the missing values (66 and 67) not supplied by the watchguard dhcp server. The watchguard will continue to manage the dhcp IP address pool, but dnsmasq will provide these values via dhcpProxy. I did allude to this in my previous post step 2.

To explain it a bit more, if the OP must support both uefi and bios clients dynamically he will need to use the latest version of dnsmasq to dynamically supply undionly.kpxe to bios clients and ipxe.efi to uefi clients.