Posts made by mr626

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.

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

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

Or do I need to recreate my master image with a 1607 build Windows 10 from scratch?

That is exactly what I was thinking before I read this last line in your post. Just start fresh. It doesn’t take too long to do if you have a list of the software and general configuration needed. This would generally take a morning’s worth of work to accomplish.

Thanks for the reply. From my own reading I’m fairly certain this is the only option, but I just wanted to check in case there was some other method I wasn’t aware of.

If anything it will probably just force me to build a much more ‘modular’ image (in the sense that configuration, settings and programs will need to be able to be reapplied to a fresh image from time to time).

Given that Microsoft have said that there will be at least a couple of anniversary updates for Windows 10 per year, I guess this means we’ll all be rebuilding our images a couple of times a year?

(not a FOG-related issue)

Hello all,

I have a Windows 10 (build 1511) image that I am currently building in a virtual machine. It is in sysprep ‘audit mode’ as is the normal practice.

My normal procedure when making changes to this image is:

-Make the required changes in the virtual machine (installing new programs, updating setting, Windows updates etc)
-Take a snapshot of the virtual machine
-Run the appropriate sysprep /rearm command, and capture the image with Fog
-Restore the virtual machine back to the snapshot (so as not to trip the rearm count).

This all works fine.

However, recently I attempted to install the 1607 update and it wouldn’t install- says that Windows can’t be upgraded in audit mode. If I take the install out of audit mode and install the 1607 update, it won’t let me sysprep it anymore (which I understand is standard behaviour- sysprep won’t work on ‘upgraded’ installs and the 1607 update is considered an upgrade).

What are the options here / what do you guys do in this situation? Or do I need to recreate my master image with a 1607 build Windows 10 from scratch?

Thanks

@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.

Hi all,

This happens every now and then when I update to a newer version of Fog. In this case today I updated from 7332 to 7476

Steps I follow:

1. Download the latest trunk via

svn checkout https://svn.code.sf.net/p/freeghost/code/trunk

2. Run the installer

/home/svn/trunk/bin# ./installfog.sh

Everything does fine with the installer, until I get to this stage

* You still need to install/update your database schema.
* This can be done by opening a web browser and going to:

 http://my ip/fog/management

* Press [Enter] key when database is updated/installed.

When I browse to that URL in my browser, I just get the normal FOG login screen. Clearing browser cache or using a different browser doesn’t make any difference. To complete the installer I just press enter anyway, and FOG still seems to work (although I do find I need to manually reset the password of the FOG unix user).

Any thoughts as to why this would happen? Of the 10 or so times I’ve updated from svn, I would estimate only 3-4 of those times I’ve actually had the correct ‘update database’ screen show up in the browser when I go to the URL directed in the install script. Or maybe it is by design, and I’m not seeing that page as nothing has changed in the database / schema?

@Sebastian-Roth I have to admit I didn’t come across the wiki entry in my search. Will make sure to check there next time.

@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!

@Sebastian-Roth said in [SVN 7009 FTP errors after image capture: Updating database failed:

@mr626 Take a look at the installer/git/svn directory. There should be …/bin/error_log/*.log with revision number in the filename.

Good tip, but unfortunately I cleared out the svn folder prior to the last pull that I did (troubleshooting an unrelated issue).

Sorry.

@Tom-Elliott said in [SVN 7009 FTP errors after image capture: Updating database failed:

@mr626 It might be a bug, that I’m completely unaware of.

If you know what version you went from when you upped to 7009, it may help me narrow the issue.

Hi Tom,

Unfortunately I can’t tell you what version I was on, unless this is logged somewhere?

@Tom-Elliott said in [SVN 7009 FTP errors after image capture: Updating database failed:

@mr626 Is this still an issue? I don’t consider this a bug considering all the changes from 1.2.0 to current trunk.

While I realize potential of issues, I try as hard as I can to make sure things just work. That said, sometimes my changes seem to be bugs, (causing other unexpected issues), in preference of simplification.

Those issues, while should be documented, are often overlooked or forgotten about.

Hi Tom,

Thanks for the reply. I’ve been using the development version of fog for a few months now, and have updating it from the trunk a few times in that period. This FTP issue only started for me after I updated to SVN 7009, hence me thinking it might have been a bug. Apologies if this is not the case.

And this is now solved. The fix was to reset the password for the fog unix user via

sudo passwd fog

I guess the installer for SVN 7009 messed it up?