@jes6309

Hi,

Just wanted to chime in and say I had the same issue, and the fix was the same- had to enable the ‘port-fast’ feature on our cisco switches.

From my reading of the cisco documentation it looks like its safe to enable this feature on all ports that are patches to ‘endpoint devices’ like PCs, printers etc.

Thanks to the posters in this thread for providing the required info. Nothing worse than finding a thread on the internet describing the exact issue you are having, and the last post is the original poster saying “I solved it” without elaborating what the fix was!

@Tom-Elliott

Thanks Tom, I figured that might be the case I just wanted to double check.

Probably not a huge priority, but would it be worth adding something to the install script that checks to see if any schema changes are needed, and if not the step about going to the URL to update it is skipped? Or at the very least, add a notice to the step that confirms that going to the URL and not seeing a schema update page is by design if there are no updates, and that you can just continue on with the installer.

@sebastian-roth said in Maintaining images on an AMD PC (via Vmware), to be deployed on Intel PCs?:

@mr626 Don’t think you will see any issues. But that’s just from the top of my head. I don’t currently use VMware so I can’t test. Give it a go and let us know. I am fairly sure you’ll see no issues. AFAIK since WinXP SP3 it is able to move between different CPUs. IDE controller, AHCI mode and such things are way more an issue. So make sure you have setup your VMs on the new system exactly the same as in the old one.

Thanks for the reply, yes I’ll be trying things out over the next few weeks so will post back with how I go.

I’m not having much luck with this, but I don’t think its an AMD -> Intel related issue.

For some reason, when I deploy the image out to the machines, I’m getting an error near the end of the sysprep minisetup phase. On the screen that says ‘Setup is applying system settings’ I’m getting: ‘Windows could not configure one or more system components. To install windows, restart the computer and then restart the installation’.

When I first got this error, I thought it must be related to the switch from Intel to AMD in the machine hosting the virtual machine. But I’ve gone back to my ‘old’ office machine and uploaded the image from there, and I’m getting the same issue.

I’ll keep investigating.

@sebastian-roth said in Maintaining images on an AMD PC (via Vmware), to be deployed on Intel PCs?:

@mr626 Don’t think you will see any issues. But that’s just from the top of my head. I don’t currently use VMware so I can’t test. Give it a go and let us know. I am fairly sure you’ll see no issues. AFAIK since WinXP SP3 it is able to move between different CPUs. IDE controller, AHCI mode and such things are way more an issue. So make sure you have setup your VMs on the new system exactly the same as in the old one.

Thanks for the reply, yes I’ll be trying things out over the next few weeks so will post back with how I go.

Hi,

Just wanted to triple check something with my setup.

Currently, I maintain my FOG images (Windows 7 and Windows 10) on Virtual Machines. These are run from VMWare Workstation on my office machine, which is running an Intel 6600 CPU.

The machines that I deploy the images to are all Intel-based, ranging from Core2Duos up to the current generation of Intels. Everything works fine.

However, I now have a new office machine, which is running a Ryzen processor. Everything is setup exactly the same, and I’ll be maintaining the FOG images on this new machine.

My concern is that there may be issues with compatibility due to the architecture change on my office machine from Intel to AMD. I vaguely remember in the past that I encountered an issue with this scenario, but I wasn’t sure if it was still an issue. I’m less concerned about the Windows 7 image- this is gradually being phased out here anyway. I assume that Windows 10 might be better able to handle these types of changes anyway?

Anyhow, have any of you dealt with this sort of scenario? Keen to hear your experiences.

For what it’s worth, I’ll post back with my own experiences too once I start deploying the images.

Thanks

No worries guys, thanks for the clarification. As long as that is clearly listed somewhere that should be fine. Would it be worth including a small note in each release announcement along the lines of “To download this release via Git, refer to wiki instructions here <link to relevant wiki page>” ?

@Wayne-Workman

Thanks for that, so I just need to start using git instead. Cool. I was confused, because even on the Fog page on Git it still refers to using svn as well:

https://github.com/FOGProject/fogproject

Hi all,

This might be a really dumb question, apologies if so.

How does one upgrade to 1.4.x from 1.3.5? I have searched the forums, the web site, the news announcements and the sourceforge page, and nowhere does it say how to actually get 1.4.x Fog.

Normally, I use the svn checkout option. Does this no longer work?

Thanks

Edit: I normally checkout the trunk, which would always get me the latest 1.3.x release. Has this changed?

Thanks again for all the replies. I’ve started working on this and have made some progress.

Just wanted to check- what is the ‘best practice’ for Windows activation during the whole process?

For example, should I have the Windows image activated against a MAK key during the build process, and then reactivate against my KMS server when I actually deploy the image?

Thanks

@george1421 Thanks for that, really appreciate it.

@Scott-Adams Thanks, am aware of it being more than just an update. Your suggestion about removing Windows.old to allow sysprep is interesting, however:

-I’m pretty sure sysprep still didn’t work for me even after removing windows.old (I remove it regardless if it exists as it is just taking up space)
-Even if it did work, you are still increasing the re-arm count

@x23piracy Thanks, but I’m not sure what that has to do with what I’m taking about here. I’m fairly familiar with sysprep and what is / isn’t required.

@george1421 Thanks for the reply- that is how I would like to try and do it for us I think.

We have a lot of GUID based programs unfortunately, so will be interesting to see how many can be install into the reference image.

So just so I’m understanding you correctly, if I am following this guide:

https://technet.microsoft.com/en-au/itpro/windows/deploy/create-a-windows-10-reference-image?f=255&MSPPError=-2147217396

the iso that you are loading in your VM is the one described in these steps? (under the sub heading 'Build the Windows 10 reference image):

---

Build the Windows 10 reference image

Once you have created your task sequence, you are ready to create the Windows 10 reference image. This will be performed by launching the task sequence from a virtual machine which will then automatically perform the reference image creation and capture process. This steps below outline the process used to boot a virtual machine using an ISO boot image created by MDT, and then execute the reference image task sequence image to create and capture the Windows 10 reference image.

Copy the E:\MDTBuildLab\Boot\MDT Build Lab x86.iso on MDT01 to C:\ISO on the Hyper-V host.

Note
Remember, in MDT you can use the x86 boot image to deploy both x86 and x64 operating system images. That’s why you can use the x86 boot image instead of the x64 boot image.

Create a virtual machine with the following settings:

Name: REFW10X64-001
Location: C:\VMs
Memory: 1024 MB
Network: External (The network that is connected to the same infrastructure as MDT01 is)
Hard disk: 60 GB (dynamic disk)
Image file: C:\ISO\MDT Build Lab x86.iso

---

@george1421 said in Windows 10- moving from 1511 to 1607 in audit mode?:

We rebuild our reference images from the beginning every quarter and install the latest OS and application updates. This is for Win7 and Win10. We use MDT to automate the process to make each quarterly build consistent. And yes you need to install 1607 from scratch and not upgrade 1511. If you use MDT then you can just copy your task sequence customizations between task sequences for each Win10 OS you choose to build. Its a little bit of a pain to do, but when a new anniversary update comes out, we just import the OS image into MDT, create a new task sequence for the new OS, and then copy and paste our custom sequences from the old OS to the new OS. It may take 15 minutes to setup a new MDT build for a new OS. But then it will build the reference computer using the light touch process (almost touch-less).

Would you mind sharing the rough process that you follow for using Fog in conjunction with MDT?

I haven’t really used MDT much before, but it is sounding like I may need to.