Posts made by Jim Graczyk

@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

@jaoyer

Please be advised that the FOG server migration, as described in the link, does not work well for existing Hosts. While the process migrates the hosts’ info that’s stored in the database, it doesn’t take into account that the new FOG server will have a new CA named exactly the same as the old server’s CA. When you follow this migration guideline, your existing hosts will not connect to the new server at a new IP address, that has a new CA unless you remove the old FOG CA from every client. This is possible thru GPOs etc, (as described by @jj=fullmer) but it’s tricky and can’t be done with FOG (since there is no way to run a snaping from the new server until the CA is already removed from the client). If your FOG system is used on more than on AD domain, then the problem becomes compounded.

I opted to harvest the certs and CA from my old server and put them on the new server. This means I had to use the old server’s IP address on the new server. This to make the old cert & CA usable by the old clients). The Reset Encryption button in the WebUI doesn’t reset the CA.

I’m working on a post to document what I did. I have several sites, each with a FOG Storage Node - something else that is omitted in the migration guide link.

I can’t say that my process will work for anyone else. I had v1.5.10 on all servers before and after I migrated. My migration took place on a network that didn’t change. My goal was to retire CEntOS 7 and move to ALMALINUX, which I did. I migrated all my images and snapins and the configuration of every host. With this approach, the Reest Encryption button was necessary, but since the CA was the same on the servers and the hosts, everything worked as it did before.

I’ll get the completed instructions posted as soon as I can.

Jim Graczyk

I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk

@JJ-Fullmer

Perhaps I misunderstand how all this is supposed to work, but there seems to be a fundamental issue - In the instructions for migrating seem to indicate that one could create a new FOG Server and migrate that new server into operating - side by side with the old server. Any path to doing this includes new certs on a new server that will have a new IP address and a new server name. One can migrate the database to retain Host, Snapins, Image, etc, but nothing is said about migrating existing FOG clients (hosts) to recognize the new FOG server as each’s FOG server. Various articles address this issue superficially by telling us to Reset Encryption for the Host using the FOG WebUI. I don’t think the Reset Encryption button is applicable when the FOG Server has all new Certs, CA, name & IP address.

In one of the posts for this topic, @JJ-Fullmer describes Powershell commands that would make a FOG clients be able to accept a new FOG server, but one is faced with how one would run those PS commands if each host is no longer able to connect to the new server to run snapins.

Part of this is just defining expectations and tell users what migration process is supported.

As of now, I’ve had a week of downtime on all that FOG does because I attempted an approach that at first, appear to provide a migration path that would have the least downtime - install a new FOG server and move to it, so the old FOG server can remain operational until we know the new one works. In this approach, DHCP would be the only thing that would need to be changes to switch to the new server, first for testing and later, permanently.

It seems this approach is a dead end - as there is no way to get the FOG Clients to connect to the new server automatically. Changing the certs to match the old server exactly can only be done using the same name and IP address. So perhaps this is they only approach that can work with existing Hosts in the system.

So, I’ve shut down the old FOG Server after pulling all existing Certs from it. I got the new server renamed to the old server’s name and IP’d to match the old server (following the Change IP process - which according to the wiki I found, includes reissuing certs - which make clients unable to connect until you mover the old certs back manually - which I did. It seems now that existing Hosts are able to connect to the server. And it may be that all but the migrated FOG Storage Nodes are connected and visible in FOG WebUI.

I feel that this approach is a workaround. In time, the certs from the original CEntOS7 install will one day expire. A migration process that includes locations, existing clients and new certificates should be defined.

Given that many Linuxes come and go, well documented upgrade paths for key software systems like FOG have become more important lately.

I’m still testing because there are still locations to migrate from CEntOS7 to AlmaLinux. I will post when I’m back up and verified.

@JJ-Fullmer

I’m running 1.5.10 on all servers (at least that’s what appears on the fog server and the fog storage nodes in the WebUI). Also, the old server was running 1.5.10 before it was shut down and when I dumped the database for migration to the new server.

I DID run into 1.5.10.xxx when downloading FOG, somehow. I used the “master” branch in git for my installs. I follow what I believe are FOG wiki pages that contain specific instructions.

If there is an issue related to upgrading from 1.5.10 to and current version of 1.5.10.xxxx, please let me know.

As I had once again f’d up and put my post under the General topic, it went unnoticed. So in the last few days, I’ve opted move the new FOG server to the Old FOG server name and IP address, and copied the /opt/fog/snapins/ssl folders and content from the old server. This is all on the servers as they were described in the initial post - not a fresh install.

I also completed the steps in the Change IP Address wiki, which specifically rebuilds the certs.

I’m now testing if I can get new and existing hosts connected.

For the record:
I was also chasing what I thought was a more fully logging version of the 0.13 client - some file named debugger.exe - that appears to be some sort of commandline realtime interface to the client that can be used to debug problems. As I have not seen any documentation regarding the innards of the FOGService and its structure, I punted on that tool.

Thanks for the help. I’ll post my results.

Jim

Please delete the version of this post I started under General

Hi and thanks for any help anyone can provide.

I’m in the middle of a FOG server 1.5.10 migration to get off of CEntOS 7 and onto AlmaLinux 9.4 running FOG 1.5.10.

I tested this process in our lab and have overcome several issues. I followed this:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

The difference is that we have several locations that also have to be migrated. I uninstalled and reinstalled the location Plugin which seemed to be required. I was able to get a 2 site deployment working correctly w images and snapins, pxe boot from the right location FOG Storage Node, etc.

The worst think I have to do was delete a Host and register with the FOG server to get it to work post imaging, aside from Reseting Host Encryption.

SO. I followed the same process (or so I think) in a production instance and have a different result. Since the lab is typically maintained to test deployments, the one thing I lacked when testing was machines that were in FOG and working pre-migration to test post migration. However, resetting a host’s encryption seemed to get all but one host to connect to FOG. Testing here was justs seeing that the fog.,log file showed proper authentication. Most testing was full deployment - image and then snapins - and these tests worked.

In the production instance, PXE booting and imagining work as expected at the 2 locations that have been migrated, but in this case, no PC is able to connect to the new FOG server - existing or reimaged.

Note: we have 8 locations, but I only migrated the FOG server and one location so far. Each location has only one Storage node - the FOG server DefaultMember at the corp HQ and a storage node at the remote site. Each storage node is in its own storage group and its own location.

We build site / domain independent images. To do this we have a DNS Alias “FOGSERVER” that points to the main FOG server A record. We use this alias in a \windows\setup\scripts\setupcomplete.cmd when running the smartinstaller.exe v0.12. at first boot.

In cases of existing hosts, I’ve have reset encryption over and again.

Oddly, in both fresh deployments of images and existing machines, all upgrade to the new FOG Service v0.13 yet the UI shows none of the host “touch” time changes.

Also in both cases (reimages and existing hosts), fog.logs show the standard No Token file / Authentication Error / Invalid security token error over and over. In 10 mins or more, the FOG client is upgraded to v0.13, but resetting the Host’s Encryption doesn’t result in the client ever getting connected. The Host shows in the UI that the OS is Windows, but all tests show “No Data” (implying the Host isn’t actually connected - which the fog.log files all show they aren’t). I’m not certain that the FOG client updates happen only after resetting encryption, but perhaps that is so.

There is a pattern in the clients - they do get upgraded, they all try to authenticate over and again, until you Reset Host Encryption. Then, after 5 attempts to connect, the FOGService on every test PC seem to stop but the service is still “running”. Restarting the FOG Service produces the same result after 5 more authentication attempts.

Here’s a typical end of fog.log:

9/16/2024 1:59:11 PM Client-Info Version: 0.13.0
9/16/2024 1:59:11 PM Client-Info OS: Windows
9/16/2024 1:59:11 PM Middleware::Authentication Waiting for authentication timeout to pass
9/16/2024 1:59:28 PM Controller Stop
9/16/2024 1:59:28 PM Service Stop requested
9/16/2024 1:59:28 PM Bus Emmiting message on channel: Status
9/16/2024 1:59:28 PM Middleware::Authentication ERROR: Could not authenticate
9/16/2024 1:59:28 PM Middleware::Authentication ERROR: Thread was being aborted.

We also see some message about not starting Looper.

--------------------------------Authentication--------------------------------
9/16/2024 3:35:01 PM Client-Info Version: 0.13.0
9/16/2024 3:35:01 PM Client-Info OS: Windows
9/16/2024 3:35:01 PM Middleware::Authentication Waiting for authentication timeout to pass
9/16/2024 3:37:01 PM Middleware::Communication Download: http://roa1fogl02.rq.priv/fog/management/other/ssl/srvpublic.crt
9/16/2024 3:37:01 PM Middleware::Authentication Cert OK
9/16/2024 3:37:01 PM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before
9/16/2024 3:37:01 PM Middleware::Authentication ERROR: Could not get security token
9/16/2024 3:37:01 PM Middleware::Authentication ERROR: Could not find file ‘C:\Program Files (x86)\FOG\token.dat’.
9/16/2024 3:37:01 PM Middleware::Communication POST URL: http://roa1fogl02.rq.priv/fog/management/index.php?sub=requestClientInfo&authorize&newService
9/16/2024 3:37:01 PM Middleware::Response Invalid security token

9/16/2024 3:37:01 PM Client-Info ERROR: Failed to authenticate, will not run Module Looper.

At this point. all clients stop logging and seem to hang - the timestamp of the fog.log file and the last entry in the log match.

In an attempt to guess what’s going on with server-to-client encryption, since the token errors appear just after the client checks the certificate, we thought maybe the FOG Client connection utilized the ssl cert in some way. We noticed that the cert only had the full server FQDN and its IP in the cert (Subject and AltSubject) (not the FOGSERVER alias we were specifying in the smartinstaller command line install run during the first reboot after imaging, so we altered the image to use the IP address and the latest version at deployment. We see no difference.

I also tried to manually install the FOG Client using both the FQDN and IP address in smartinstaller run manually - and again - still the same result.

I’m thinking is that the issue is on the server side and beyond our understanding.

Let me know if any additional info is needed and thanks for any help you can provide.

Jim Graczyk

Hi and thanks for any help anyone can provide.

I’m in the middle of a FOG server 1.5.10 migration to get off of CEntOS 7 and onto AlmaLinux 9.4 running FOG 1.5.10.

I tested this process in our lab and have overcome several issues. I followed this:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

The difference is that we have several locations that also have to be migrated. I uninstalled and reinstalled the location Plugin which seemed to be required. I was able to get a 2 site deployment working correctly w images and snapins, pxe boot from the right location FOG Storage Node, etc.

The worst think I have to do was delete a Host and register with the FOG server to get it to work post imaging, aside from Reseting Host Encryption.

SO. I followed the same process (or so I think) in a production instance and have a different result. Since the lab is typically maintained to test deployments, the one thing I lacked when testing was machines that were in FOG and working pre-migration to test post migration. However, resetting a host’s encryption seemed to get all but one host to connect to FOG. Testing here was justs seeing that the fog.,log file showed proper authentication. Most testing was full deployment - image and then snapins - and these tests worked.

In the production instance, PXE booting and imagining work as expected at the 2 locations that have been migrated, but in this case, no PC is able to connect to the new FOG server - existing or reimaged.

Note: we have 8 locations, but I only migrated the FOG server and one location so far. Each location has only one Storage node - the FOG server DefaultMember at the corp HQ and a storage node at the remote site. Each storage node is in its own storage group and its own location.

We build site / domain independent images. To do this we have a DNS Alias “FOGSERVER” that points to the main FOG server A record. We use this alias in a \windows\setup\scripts\setupcomplete.cmd when running the smartinstaller.exe v0.12. at first boot.

In cases of existing hosts, I’ve have reset encryption over and again.

Oddly, in both fresh deployments of images and existing machines, all upgrade to the new FOG Service v0.13 yet the UI shows none of the host “touch” time changes.

Also in both cases (reimages and existing hosts), fog.logs show the standard No Token file / Authentication Error / Invalid security token error over and over. In 10 mins or more, the FOG client is upgraded to v0.13, but resetting the Host’s Encryption doesn’t result in the client ever getting connected. The Host shows in the UI that the OS is Windows, but all tests show “No Data” (implying the Host isn’t actually connected - which the fog.log files all show they aren’t). I’m not certain that the FOG client updates happen only after resetting encryption, but perhaps that is so.

There is a pattern in the clients - they do get upgraded, they all try to authenticate over and again, until you Reset Host Encryption. Then, after 5 attempts to connect, the FOGService on every test PC seem to stop but the service is still “running”. Restarting the FOG Service produces the same result after 5 more authentication attempts.

Here’s a typical end of fog.log:

---

9/16/2024 1:59:11 PM Client-Info Version: 0.13.0
9/16/2024 1:59:11 PM Client-Info OS: Windows
9/16/2024 1:59:11 PM Middleware::Authentication Waiting for authentication timeout to pass
9/16/2024 1:59:28 PM Controller Stop
9/16/2024 1:59:28 PM Service Stop requested
9/16/2024 1:59:28 PM Bus Emmiting message on channel: Status
9/16/2024 1:59:28 PM Middleware::Authentication ERROR: Could not authenticate
9/16/2024 1:59:28 PM Middleware::Authentication ERROR: Thread was being aborted.

We also see some message about not starting Looper.

--------------------------------Authentication--------------------------------

9/16/2024 3:35:01 PM Client-Info Version: 0.13.0
9/16/2024 3:35:01 PM Client-Info OS: Windows
9/16/2024 3:35:01 PM Middleware::Authentication Waiting for authentication timeout to pass
9/16/2024 3:37:01 PM Middleware::Communication Download: http://roa1fogl02.rq.priv/fog/management/other/ssl/srvpublic.crt
9/16/2024 3:37:01 PM Middleware::Authentication Cert OK
9/16/2024 3:37:01 PM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before
9/16/2024 3:37:01 PM Middleware::Authentication ERROR: Could not get security token
9/16/2024 3:37:01 PM Middleware::Authentication ERROR: Could not find file ‘C:\Program Files (x86)\FOG\token.dat’.
9/16/2024 3:37:01 PM Middleware::Communication POST URL: http://roa1fogl02.rq.priv/fog/management/index.php?sub=requestClientInfo&authorize&newService
9/16/2024 3:37:01 PM Middleware::Response Invalid security token

9/16/2024 3:37:01 PM Client-Info ERROR: Failed to authenticate, will not run Module Looper.

At this point. all clients stop logging and seem to hang - the timestamp of the fog.log file and the last entry in the log match.

In an attempt to guess what’s going on with server-to-client encryption, since the token errors appear just after the client checks the certificate, we thought maybe the FOG Client connection utilized the ssl cert in some way. We noticed that the cert only had the full server FQDN and its IP in the cert (Subject and AltSubject) (not the FOGSERVER alias we were specifying in the smartinstaller command line install run during the first reboot after imaging, so we altered the image to use the IP address and the latest version at deployment. We see no difference.

I also tried to manually install the FOG Client using both the FQDN and IP address in smartinstaller run manually - and again - still the same result.

I’m thinking is that the issue is on the server side and beyond our understanding.

Let me know if any additional info is needed and thanks for any help you can provide.

Jim Graczyk

@wayne-workman

Update:

Replication wasn’t responsible for any of the traffic we’re seeing. We disable replication in the FOG Configuration area and still saw the same 2 GB per day per FOG Storage Node. Our bandwidth monitor showed the traffic to be both TCP and HTTP. We then stopped the services FOGImageReplicator, FOGSnapinReplicator, and FOGSnapinHash services. Still no change. We saw a constant 160-190kb/s traffic from the Main FOG server to the Storage Node. So, I captured packets - only 1000, but that took only 5 seconds. I saw what looked like the storage node replication log transmitted from the storage node to the main FOG Server. Most of the traffic was from the main FOG server to the storage node, but I wouldn’t tell much from the packet.

In the end, I was able to stop almost all traffic by shutting down all FOG services, including the FOGScheduler.

So the questions now are:

Is there any documentation that explains what each service does and what we’re breaking by turning each off?

Are the negative effects mitigated by running any of the service daily?

Any assistance is appreciated.

Jim Graczyk

@wayne-workman

Wow!!! I never would have expected that. I would assume an MD5 hash on each side would be the best way to go.

My design philosophy is always to go as thin as you can manage. It’s based on the notion that even though GB Ethernet is everywhere and my internet connection is 300 x 30, CPUs outperform disk, disks outperform networks, and WAN connection will remain a problem for the rest of my life.

At present, we’re working over VERY thin pipes, but for my future reference, is there any way to manage the frequency of image and snapin replication tasks? If I have a lot of images, I’d likely set replication for once a day, at most, especially with many locations.

Thanks for all your help.

Preliminary info indicates we may have made FOG traffic a footnote compare to all inter-site traffic, instead of being the top user by a factor of 10.

Thanks - more later…
Jim Graczyk

@george1421

Thanks for this fine detailed info. Our possible fallback position might be a full fog server at the remote site, but we have only a dozen or less PC per site. I don’t look forward to trying to keep 5 FOG servers config’d identically.

Also, we are aware that each FOG server has it’s own cert, so moving PCs from server to server would be a challenge. Half of our PCs are laptops with users moving from location to location. With one FOG server, we can easily move a PC to a different location (where ever the user is that day), and re-image. Our approach to Snapins is automatically site aware (DFS and SAMBA), and our FOG Snapin is just a generic 15K stub. All our snapins are accessed over SMB. We rely on FOG to manage and execute Snapins, but not so much store them.

Our bandwidth monitoring is showing very little traffic from the FOG client to the Main FOG server. Personally, I can’t understand how or why the Main FOG server would transmit 1 GB in 12 hours to a server that is in sync. I wondered about the Snapin Hash Global Enable, but our 40 snapins amount to less than 1 MB of data, so I don’t see it there.

We’ve used the FOG Linux Service Enable section of FOG Configuration to uncheck these parameters:
IMAGEREPLICATORGLOBALENABLED
SNAPINREPLICATORGLOBALENABLED
SNAPINHASHGLOBALENABLED

We’ll report back our results after a day.

thanks,

Jim Graczyk

When using the Location plug in, with one storage node per location, how does one turn off all file replication from the Main FOG Server to a Storage Node, but still allow the FOG Client to utilize the contents of the storage node at the location? We’re assuming when one unchecks replication on Snapins and Image, the FOG system will no long use the content on the Storage Node (PXE, Snapins and Images). Our content is up to date on all storage nodes (and unchanging), so we want the client to use the remote content, but we want the Main FOG server to stop talking to the Storage Nodes.

Background:
We’re using FOG 1.5.0 RC9 in production, with 8 storage nodes, all separated from the Main FOG server by VPN. We’re using the Location Plugin, so we have 9 locations total, one storage node per location. We have 40 or so Snapins (all of which are 15Kbytes) and 4 images, all configured in the FOG GUI to replicate from the Main FOG server to each storage node.

We’re seeing 1 GB/day of traffic between the Main FOG server and each Storage Node, with most traffic going from the main fog server to the storage node (70/30 split). 4 of our Storage nodes are on sites with 4GLTE (Metered) connections. This amount of data per day is unsustainable and costing thousands of dollars a month.

We have set all Storage Nodes to Replicate at 5 kb/s, hoping this would solve the data use issue, but it has had no effect.

Our content (Images and Snapins) is very static. We would like to manually sync to storage nodes if we have any changes at the Main FOG Server and we’ll do this very infrequently. We already have scripts for this. We would like to stop replication from the Main FOG Server to the Storage Nodes but still use the Storage Nodes and Location Plugin as if replication were constantly running.

If we can’t do this, we’ll have to turn FOG off everywhere. We just can’t sustain the cost.

Any suggestions would be appreciated.

Jim Graczyk

@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

@tom-elliott

Tom,

I have no idea if it’s related to the version I’m running. I have 2 instances off FOG, so not a lot to go on. I can say that the same Snapin definition in my Lab remains as it was entered. The Lab is on a recent working branch. For this production version, we’re sticking with RCs. So it could be a non-issue.

We’ll wait for RC10 release to update productionn and see what happens. If it’s not too much trouble, could someone give me a way to delete this snapin in SQL. I have it disassociated from all replication, hosts, storage groups, etc - anything I can do from the UI. If not, it’s just one snapin so NBD. I don’t think I can recreate it and expect the new one to survive any better than the original. It’s a snapin used only to make images, so it’s seldom used.

Consider this Solved and we’ll take it up later, if need be.

Thanks,
JIm

I normally create snapins that are exes, but I created one Snapin Pack and found the system has dorked the argument string some where along the way.

The argument for this snapin pack was:
/c “[FOG_SNAPIN_PATH]\copyFOGExe.cmd”

Here’s the screenshot of the present value:

I attempted to delete this snapin and re-create it but I cannot delete it. When I hit delete, nothing happens. After waiting a long time and listing all snapins, it’s still there.

Any ideas?

This could be a generic issue or related to the RC.

Thanks,

Jim

I’m constantly logging into FOG from all over the place. Every time I log in, I have to wait many seconds and sometimes minutes before the Dashboard is displayed. Often, I just need to deploy a Host or single Snapin. I’m not overly concerned with the overall operation of FOG EVERY time I log in. For those of us with many locations, strung together with less-than-robust connections, the polling of the storage nodes (sometime many on fast connections, more often less than 10 over slow connections), delays the display of the Dashboard excessively.

Please consider adding to the FOG Configuration area a variable with a pull-down where a FOG admin can select any one of the large Icons on the top menu as the page to display after the user logs in. This parameter for be set for the entire web site and not for the user. We already have control of whether the top level pages show a list or a search dialog, so we’ll have great control of the responsiveness of the UI.

Thanks,

Jim

@Sebastian-Roth
@george1421

Guys,

Is there any way to alter the choice of pages that the Web UI goes to upon sign in?

I’m seeing very long signin times but the web UI is mostly very fast in my installations. I’ve got 9 remotes sites, each with 1 storage node, some of the sights are connected in over 4G LTE.

Signing into FOG takes variously long times, depending on how the 9 connections are doing.

I could do without the dashboard page and the load it generates. I’d be happy if the default page were anything but the Dashboard.

Jim

@tom-elliott

Tom,

Sorry about the delay, but I wanted to see more data before responding.

The time zone change resolved a big part of the problem. All the times are now making more sense. I’m guessing the log store UTC because after changing the timezone setting, all Snapin Histories are as they should be - no time shifts.

I can only suppose that to have the times appear as they did originally, the initial time stamps may have been coming from the client. I would suggest this isn’t a good idea since PCs are notoriously out of sync, but these days with SNTP, not so much. One would think it would be desirable to use all time stamps from the server.

So… Thanks very much for pointing that out to me. I once knew timezone was a setting but seem to have forgotten…

To be thorough, I do want to point out something, just to be sure that what I’m seeing is by design.

Attached is a screenshot of the snapin history after a deployment for a machine.

Please note that there are only 5 Start Times for all 17 Snapins. It seems that the start time is only recorded for the first Snapin in a series of snapins executed in one pass of the FOG Service. Given the current report, one can determine the actual start time of a particular Snapin by doing the math (Add the previous snapin’s duration to the posted start time for the task). One can also determine the duration of each individual snapin by subtracting the previous snapin’s duration from the posted snapin duration.

Personally, I’d like to see the snapin start time be the start time for each snapin, not the start time of a group of snapins that just happen to run sequentially. Simialrly, I’d also like to see the duration as the duration of a single snapin, not a group.

If the current approach is by design, then ok. I certainly can live with what we have.

Thanks,

Jim

@tom-elliott

Tom,

Just so you have all the info -
I was operating under the premise that I could cancel only one of many Snapins scheduled during a full deploy action. This may be a timing issue, but when I canceled the undesired Snapin, the first Snapin in the list was already In-Progress. The no Snapins ran after I canceled one. The Host’s Snapin History shows the 2nd Snapin was canceled, when I actual canceled the 7th.

Jim

@robtitian16

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

Jim

@jim-graczyk My apologies. Can someone move this to the Development area?