Word - temp environmental variable
-
Server
- FOG Version: 1.2.0
- OS: Ubuntu 14.04
Client
- Service Version: Dell Optiplex 7010
- OS: Windows 10
My images upload and download fine on the Dell 7010 but as soon as anyone logs into the domain and opens Word they get an error that says: Word could not create the work file. Check the temp environmental variable.
I only get this on the 7010s. Not on any other models we use in FOG.
Server
- FOG Version:
- OS:
Client
- Service Version:
- OS:
Description
Server
- FOG Version: 1.2.0
- OS: Ubuntu 14.04
Client
- Service Version: Dell Optiplex 7010
- OS: Windows 10
My images upload and download fine on the Dell 7010 but as soon as anyone logs into the domain and opens Word they get an error that says: Word could not create the work file. Check the temp environmental variable.
I only get this on the 7010s. Not on any other models we use in FOG.
-
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
-
I have one image per hardware model. It is not an issue on other models.
-
@John-Johnson Then something else is configured differently on this 7010 from all of the other models.
FOG Only captures images and deploy’s them. It does not modify the files within in any shape.
-
@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.
-
This article seems to have fixed the issue: https://support.microsoft.com/en-us/kb/822005
-
@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?
-
@george1421 I can fix this image and use it now. Thanks
-
@george1421 I spoke too soon. After pushing it up and reopening Word I still get the same error.
-
@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?
-
@george1421 It appeared to be fixed. I checked it under my login and it worked. I took it off the domain, sysprepped it and pushed it back up. After it finished I logged in again and got the same error so the fix did not really work.
-
@John-Johnson Again, I want to restate this is not a FOG issue.
You are sysprepping it so that is fine/good.
- Are you using an unattend.xml file? If so, that is good.
- If you are using the unattend.xml file does it contain this line:
<CopyProfile>true</CopyProfile>?? - And when you fixed the reference image, were you logged in as the
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. -
@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.
-
@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.
-
@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 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.
-
@george1421 I am thinking that maybe this is a result of upgrading to the Anniversary update after installing Office. It has a way of changing things. So I am going to rebuild, do the Anniversary update and then install Office.
-
@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).
-
I was able to make an image successfully. Windows 10 is a different animal and you have to do things just right or it will fail.
-
@John-Johnson What is it that you did? I’m asking for future readers.
