Best posts made by Jim Graczyk

@sebastian-roth
@Taspharel
@george1421

All of the info provided lent itself to the ultimate solution…

For anyone who wants to create images on one fog server and have them used on a completely separate, unique and different FOG Server, here’s the process I used.

We’ll create an image that has the FOGService on it associated with the first FOG Server (FOGServer1) by running Sysprep with shutdown. We’ll install the second FOG Server (FOGServer2) and acquire the certs from it by installing the FOGService on a PC and associating it with FOGServer2. We’ll edit the uploaded disk by attaching it as a “D:” drive to a PC and create or add to the SetupComplete.cmd file to load the FOGServer2 certs after Sysprep completes.

Here are the steps:

• Build the image PC with OS, applications, etc. - whatever you want already installed. I subscribe to the notion that a windows image should contain the MS OS CD installed, FOGService Installed and then the rest of the content should come from Snapins. As little as possible should be done by hand because can seldom repeat the process if we have to. For this process, however, it doesn’t matter.

• Install the FOG Client Service and associate it with the first FOG Server (FOGServer1). As stated above, I use Snapins to deploy content the makes up my images.

• Run Sysprep with shutdown, then capture the image to the FOG server (FOGServer1).

• Install the FOG Client Service on a PC associated with the 2nd FOG server (FOGServer2), accepting all defaults.

• In the FOG folder (C:\Program Files\FOG or c:\Program Files (x86)\FOG) copy files ca.cert.der and fog.ca.cer to external storage

• Deploy the image from FOGServer1 to a disk (a virtual is vastly perferred) with Shutdown. Do not let the machine attached to the disk boot.

• Mount the disk to another computer as an additional disk (as in D Drive).

• Using this other computer, edit the contents of the sysprep’d drive (D Drive)

• Copy ca.cert.der and fog.ca.cer to the “D:\windows\setup\scripts” folder

• Create SetupComplete.CMD file in “D:\windows\setup\scripts”, or add to the existing file

• Add these lines for a 32 bit OS:
  copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles%\FOG\ca.cert.der”
  copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles%\FOG\fog.ca.cer”
  certutil -delstore Root “FOG Server CA”
  certutil -delstore Root “FOG Project”
  certutil -addstore Root “%programfiles%\FOG\ca.cert.der”
  certutil -addstore Root “%programfiles%\FOG\fog.ca.cer”

• Add these lines for a 64 bit OS:
  copy /y %windir%\Setup\Scripts\ca.cert.der “%programfiles(x86)%\FOG\ca.cert.der”
  copy /y %windir%\Setup\Scripts\fog.ca.cer “%programfiles(x86)%\FOG\fog.ca.cer”
  certutil -delstore Root “FOG Server CA”
  certutil -delstore Root “FOG Project”
  certutil -addstore Root “%programfiles(x86)%\FOG\ca.cert.der”
  certutil -addstore Root “%programfiles(x86)%\FOG\fog.ca.cer”

• Dismount the additional disk, connect it to a machine associated with FOGServer2 as the system drive (C:), and capture the image to FOGServer2.

• When Deploying the image to additional machines from FOGServer2, the machine will associate with the FOG Server2 but will not join the domain or run Snapins until you Reset Encryption for the new host (button found at the top of the “General” tab for the host).

• One caveat - I use a DNS alias for all FOG Servers (creatively, I chose fogserver) so I don’t have to worry about FOG server name differences. If your FOGServer1 and FOGServer2 are in the same DNS zones, this won’t work, so if you have different FOG server names, you can save the setting,json file from the \program files\FOG folder from a PC associated FOGServer2 or just edit the one with the new FOG server name in it. When you’ve mount the imaged disk as an additional drive, copy the altered settings.json file to the \windows\setup\scripts folder (along with the certs) and add an additional ‘copy’ command to SetupComplete.cmd to get the file into the FOG folder (just like the certs). I haven’t tested this, so hopefully some who knows better will comment.

While the above process is a pain to execute for each image you create, each time you need to associate it with a new FOG Server, I find it far more cost effective than uninstalling the FOG Service and reinstalling it after imaging each PC.

• Please note that I had to place some very odd quotes around some paths because drive letters become emojis d: …

Jim Graczyk

@robtitian16

I believe I’ve seen this when I’ve forgotten to disable Secure Boot in the Hyper-V VM definition.

Jim

@tom-elliott

Here are the screenshots for each step of the fog iPXE process:

@Tom-Elliott said in Storage Group in Dashboard Showing 1 Slot in QUEUE But No Tasks Exist:

mysql fixing

I ran the maintenance script found at the bottom of this link:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

Several lines deleted rows. The problem is resolved.

Thanks,

Jim

@themcv

OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.

I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.

Go Figure…

Thanks and sorry for the trouble…

Jim

@tom-elliott

Tom - I tested this on several Gen2 VMs and they all extended to the fill disk size.

Thanks - SOLVED.

Jim

Server

• FOG Version: 1.5.0
• OS: CEntOS7

Client

• Service Version: 0.11.12
• OS: Win7

Description

I’m working on a Snapin for a VPN client install (SoftEther VPN - great freeware, recommend it highly - AND I have a working installation process).

The result is the VPN Client package testing has resulted in the FOG client informing FOG about the MAC address on the VPN vNICs the software creates.

While looking for a way to Dis-Approve Pending MAC addresses, I click on the + button (Add MAC Address) on the General form of the a Host page. Doing so caused the page to list many new places to add MAC addresses:

This screen shot is at 33% and there are 28 similar pages before one get’s to the bottom of the webpage.

Upon hitting the + to add MACs, the webpage becomes unresponsive. I cannot get a new page to come up - at least not too easily - and the server and workstation show substantial increases in load. From task manager:

I’m forced to close the browser and re-log in to be able to continue.

This only appear to occur on hosts with several pending MAC addresses and it may only occur what a browser is zoomed in.

Jim

@avaryan

Thanks. I haven’t had the need for the Access Control Plugin. I supposed it’s time. Thanks. I still believe it should be an option. The Dashboard is a good page, but it’s not the most efficient thing when you want to get on with FOG tasks.

Jim

@birvin

I would also offer the suggestion that you separate the /images folder onto a separate virtual disk. You Could do this without rebuilding. I’ve used USB disks on ‘toaster’ that are mounted as /images as well. In either case, this allows use to expand the /images folder w/o messing with the rest of the install.

Wayne is an expert, so maybe my approach is more work. I’ve backed into this problem over and again, as image space has grown (mostly from uploads, in my case), but we were able to mount the old volume as /oldimages, mount the new empty volume as /images, copy image, then unmount the /oldimages volume. If I recall, it was only a matter of mess with fstab in my case.

Just a thought.

Jim

@Jim-Graczyk

The wiki on migration covers migrating a single FOG server using the only workable process, so I’ll leave that alone.

I think my issue with the entire “Server Migration” process is that it requires you take FOG down at the onset of the process - before you attempt to install FOG on the new server. This obviously stops all the PC IT maintenance processes FOG provides IT support, but also FOG’s benefits to the end users of the hosts, until the new server/system is back up and working.

I’ve used FOG on a fairly large scale - some instances have 10+ remote sites, each with its own FOG Storage Node. To say that shutting it down before starting migration is inconvenient to the business is an understatement. Storage node migration didn’t require that the storage node had use the same IP as the old storage node - so that helped.

I hope that my initial post to you comes up when other FOG users search “FOG Migration”, so they don’t waste the time I did trying to build a completely new FOG system, including storage nodes, to cut over to, only to find that you can image PCs and create new hosts, but the exiting host would not talk to the new server system - so all the existing host configuration is lost (a large chunk of work). Ironically, there are numerous FOG wikis that address most issues that I ran into - creating new certs, the ever-present Reset Encryption on the FOG Client, etc., but none mentioned that the CA of the old system HAD to be used in place of the new.

I’m glad there was some way forward without having to reconfigure everything manually, but like many things in FOG wikis, everything in them is true, but context and limitations are not defined at the beginning. Even the migration process link didn’t spell out requirements, nor include remote sites and storage nodes. It needs to spell out that harvesting the CA and certs and using the old server’s IP address are as important as the database, snapins, and images - and this is the ONLY way to migrate.

So - a suggestion to the great minds working on FOG:

Create a way to change the FOG Client CA in one step - delete old and replace new - from within the FOG Client. This could be something issued from the old FOG server, for security reasons. CA deletion should also be built into the FOG Client Installation MSI/EXE. I use FOG to build portable Windows images that are company and FOG server independent. The FOG client is installed at the initial boot and replaced in the image as FOG evolves.

If that capability could be added, migration would be possible such that the new system w database, snapins, images, host configs, could be build out with multi-storage nodes and multi-locations, side-by-side with the old FOG system, gated only by DHCP boot settings at each site (IP broadcast space).

Jim Graczyk