@Wayne-Workman said in Black Screen on Surface Pro 4:

@Tom-Elliott said in Black Screen on Surface Pro 4:

@Psycholiquid I’ll but the 7156 efi files up on rc-3 so this shouldn’t be an issue anymore.

Perhaps even label them differently than just replacing all of them?

Could call the 7156 ipxe.efi file something like surfspro.efi or ipxe7156.efi ?

I want to keep the latest efi files, and these ones that work for the surface too.

If someone ( @Psycholiquid ) could post a complete packet capture of a DHCP conversation with a surface 4, I’ll see what I can do in the way of a vendor class for DHCP.

Man would love to if I knew how…

@Tom-Elliott It worked to switch out the files. Not sure why but it did work.

@fry_p Thanks I’ll give tha ta try and report back

This was working before I updated to the latest trunk so not sure what might have changed. (Updated today. I was about a month or two behind)

Attempting to register the host I get no screen after choosing Full Registration and Inventory.

I have tested with other machines and they are working. Not sure if it is running in the background and it is a video issue or if it is bombing out for some reason. Any way to find out?

@MRCUR I actually put it in both out of habit, if you look at my scripts, (I think I have them posted) I delete the xml from both locations. But again this is habit form doing it for so many years.

@Boyan-Biandov Your image has a driver it doesn’t like if you are getting that, for the most part I don’t really audit mode anymore. I do what I need to do in Windows and go straight to OOBE from there makes it cleaner and easier to deal with. I am still using the same XML I have posted here and it still works so you might want to check your drivers.

Always keep in mind that you can get past that by hitting Shift F10 sometimes and running Explorer. Then you can check the Setup,log in the Panther folder to see what is happening.

@gwhitfield Yeah that was the same issue I was having and had to deploy the disabled service and start after sysprep to overcome. Now I agree that the old server didnt do that and nor did mine, but once I went to using trunk I had to switch to this method.

@gwhitfield Small question why are you trying to rename the computer before sysprepping? Your master image should never join the domain. This can cause issues when you sysprep and that image still has some of the policies of your domain in the image.

This can cause auto logon to not work along with a bunch of other issues. That being said I have done it to get some software to work then dropped it back, reset the Admin password to blank and it worked fine but I really don’t recommend it.

@gwhitfield Also keep in mind I only see this reaction with Windows 7 after I applied some updates. So it could be a mix of things causing it.

@gwhitfield There is an issue I have that if the service is running during sysprep is causes issue that mimic what you are seeing, So I just disabled it and then let the commands turn it back on and set it to start once sysprep is complete.

@gwhitfield Try this, dis able the fog service in your pre sysrepped image and add these lines to your unattend.xml if you are using one:

<FirstLogonCommands>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>del /Q /F c:\windows\system32\sysprep\unattend.xml</CommandLine>
                    <Order>1</Order>
                    <Description>Deletes unattend.xml</Description>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>del /Q /F c:\windows\Panther\unattend.xml</CommandLine>
                    <Description>Deletes unattend.xml</Description>
                    <Order>2</Order>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>sc config FOGService start= auto</CommandLine>
                    <Description>Changes FOG server to Automatic</Description>
                    <Order>3</Order>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <CommandLine>net start FOGService</CommandLine>
                    <Description>Starts FOG service </Description>
                    <Order>4</Order>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
            </FirstLogonCommands>

All this happens in the OOBE phase of the sysprep. If your not using unattend try this batch file to run after it comes up:

sc config FOGService start= auto
net start FOGService

paste that into a text file and save as SetupComplete.cmd. Then place the file in the following area: %WINDIR%\Setup\Scripts\

Then sysprep.

@Tom-Elliott perhaps this is the same issue I have where he needs to disable the service until after the sysprep is complete?

@gwhitfield I can tell you all mine are checked , if that helps.

@gwhitfield That is teh same thing I do with 3 autologons, but I am not seeing the enforced part in my version. Might be something new I haven’t updated to yet.

@gwhitfield I am not running the same trunk as you, but it would seem that if you stayed logged out it might change. Try setting the name in FOG on the host and stayed logged out of the machine and see if it restarts.

The only reason I think this is because of the “HostnameChanger Users still logged in and enforce is disabled, delaying any further actions”

What are you getting from the log at c:\fog.log on the client? And by that I mean I need to see the Hostname Changer part of the log

I was able to get past this. I guess it is a Windows 10 thing but you have to run the chkdsk scan from within Windows and then let it reboot. It will tell you it is dirty as soon as you do it and will correctly. FOG working great again (Not that it wasn’t stupid Windows)

@Tom-Elliott Of?

@sudburr VM