@John-Johnson While I can’t speak for your process, we just completed the 1607 refresh of our golden image. We use MDT to go from DVD to our golden image (and not go the upgrade route). The image works properly in the test lab and we are about ready to release it for use.
I can tell you for Win10 CBB v1607 you MUST install the Sep 20 accumulative update or your systems will not get updated from WSUS (ever). There are documented bugs in 1607 (big time).
@John-Johnson said in Word - temp environmental variable:
@george1421 I am using an unattend.xml file and the fix was done under administrator. Yes the line is in the sysprep file. Our file is called unattend64.xml to keep it separate from the 32 bit machines.
Understood, we use a similar structure for the unattend.xml file. That is disappointing that this setting did not remain after sysprep. At this point I’m not sure what to look at next.
@John-Johnson said in Word - temp environmental variable:
@Tom-Elliott I’m not blaming it on fog. I know it has something to do with the way this machine is handling Office but I can’t figure out what is different than any other machine I image.
No problem, just trying to make it clear to future readers of this thread where the problem is not.
@John-Johnson Again, I want to restate this is not a FOG issue.
You are sysprepping it so that is fine/good.
<CopyProfile>true</CopyProfile> ??Administrator?If you answered no to any of the questions above, I understand how/why the fix is gone. Because when you sysprep the image all profiles are reset except the administrator’s account. When you have the copyprofile set to true then when you sysprep the image the Administrator’s account is copied to the default profile. And the default profile is the basis for all new users after imaging is complete.
@John-Johnson But if you fix it after the image has been deployed then its ok?
If you fix it after its deployed does it fix it for everyone or only the user you fixed on?
@John-Johnson So is that something you can do to the golden image for this hardware platform?
Are you using a sysprep’d image to where you can update this in the admin profile and then use the copyto option in the unattend.xml file to copy it to the default profile?
@John-Johnson said in Word - temp environmental variable:
I have one image per hardware model. It is not an issue on other models.
But potentially there could be something not right with just this image. That is why I asked you about one image per model or one image for all.
(this isn’t intended to sound bad, but it does a bit) But your assertion that it only happens with the 7010 is flawed since you can’t compare a, lets say 790 image against a 7010 image because the captured image is setup differently. If you had a single image for all then that would be something else, why is it only happening with the 7010 vs 790s
I would read over the links I posted to see if they have any merit to resolve your issue. You may have to go back to the golden image for the 7010 to fix the root of the problem.
@dureal99d change up the order put the
dhcp-boot=tag:BC_UEFI,tag:r503u,intel7156.efi,,192.68.1.109
before the one with ipxe.efi. (just guessing)
Lets be clear that this is not a fog issue because fog doesn’t work differently for different hardware platforms (unless you are switching operating systems like linux to windows).
Do you have one windows image per hardware model or do you have one windows image for all hardware models?
I did find this article that seems to address your issue: https://support.microsoft.com/en-us/kb/2285187
@george1421 said in Serve different types of .efi boot files:
dhcp-boot=tag:r503u,intel7156.efi,192.68.1.109
You might want to update that line to something like this
dhcp-boot=tag:BC_UEFI,tag:r503u,intel7156.efi,,192.68.1.109
That will create an AND condition. So it has to be in uefi mode AND the mac address has to match.
@dureal99d I think I can explain this (understand I’m still learning dnsmasq’s insides too.).
dhcp-mac=set:r503u,50:46:5d:98:6f:3c
dhcp-boot=net:IA32_UEFI,i386-efi/ipxe.efi,,192.168.1.109
dhcp-boot=net:BC_UEFI,ipxe.efi,,192.168.1.109
dhcp-boot=net:X86-64_EFI,ipxe.efi,,192.168.1.109
dhcp-boot=tag:r503u,intel7156.efi,,192.68.1.109
We had a discussion when we were setting up the initial test. if you look at the tag:r503u line. What is matching there?? Look its the mac address so the only condition you have is that the mac address has to be X. So every time dnsmasq see mac address X it will send out intel7156.efi.
Now why in efi mode?? This one has me a bit stumped. Logic would say first match wins, in that case this line would be the first match.
dhcp-boot=net:BC_UEFI,ipxe.efi,,192.168.1.109
So that would explain why ipxe.efi is being sent because the only test here is it be in efi mode.
But in my testing I was seeing that the last match was winning. So if that thought is true. This one should be the winning line.
dhcp-boot=tag:r503u,intel7156.efi,,192.68.1.109
@mageta52 Ok, no problem.
The proper tcpdump filter that will show us what is going on without showing things that you shouldn’t post to an open forum is this.
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
This will record only dhcp, tftp, and dhcpProxy traffic. Start this running on the FOG server then pxe boot the target computer (on the same subnet) until the target errors out then hit ctrl-C on tcpdump and review with wireshark or post it hear for review.
@pencils yes it is relative. The tftp files are downloaded from /tftpboot that is the root of the tftp path.
Is this a FOG created menu entry or something you created by hand in 1.2.0?
On a side node, fog has the ability now to create / edit the advanced menu from inside the web gui, that is something new with 1.3.0
@george1421 while I don’t recommend this, because that file missing tells me something else is going on here that we are not aware of and that is a concern. You could recreate that file. Its just a text file with the permissions of 755.
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://192.168.1.133/fog/service/ipxe/boot.php##params
@pencils well indeed default.ipxe is missing, why? All of the other stuff appears to be there? This is very strange.
Lets start with some basics.
is 192.168.1.133 your fog server?
what do you get when you key this in from the linux console on your fog server ls -la /tftpboot ?
@dureal99d I would say this line is important
dnsmasq-dhcp[1283]: 1735601825 tags: BC_UEFI, r503u, enp8s0
This tells me that you have the match mac address right because there is the r503u tag. To prove it change the mac address slightly and than pxe boot again. That tag should disappear. (Don’t forget to change it back because this part IS working)
So the dhcp-boot section is failing to match for us. This is just me guessing but change
#this line
dhcp-boot=net:r503u,intel7156.efi,,192.68.1.109
#to this
dhcp-boot=tag:r503u,intel7156.efi,,192.68.1.109
@dureal99d well then you know the basics then you probably want to look into this filter
dhcp-mac=set:mac_01,<mac_to_match>
so then you will need a dhcp-boot with the conditional test for mac_01 and the name of the boot file you want to send.
@mageta52 I don’t have one of the nuc’s in front of me. I seemed to recall a check box its either uefi on or off (but don’t quote me on that). And then there was a personality setting.
If you don’t know what mode it is (I can’t tell from your last post) and your fog server and nuc are on the same subnet we can use the fog server to record the dhcp booting process and that will tell us what the client is saying during bootup.