@svalding What you’re looking for is the access control plugin. Enable the FOG Plugin system in web ui -> fog configuration -> fog settings -> plugins -> enable the plugin system. Then in the plugins area (on the ribbon) install the access control plugin. If you search the forums, you can find a couple examples of it’s usage.

@lorentedford I don’t need a video. Don’t use sh to run the installer, just do a ./installfog.sh These instructions will work: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

I did start work on the script this morning before work, It’ll be done tonight or tomorrow morning. I’ll post a link when it’s done.

@jhalbert Here’s the script:
https://github.com/FOGProject/fog-community-scripts/tree/master/delete-extra-macs-on-host
Set the variables at the top, and set it to run on a schedule in cron.

@sebastian-roth Just tested RC 9. The host doesn’t show up in the pending MACs report, but does show up in the ‘list all’ in Host Management, but is unapproved at that point. Clicking a little link towards the top of it’s general page will approve it.

So, from what I’m seeing, the pending MACs list has something wrong with it, but the auto-registration is working.

@sebastian-roth Things like that are what concern me about using UUIDs… In a perfect world where all manufacturers actually follow standards, it’d be great. We should consider ourselves lucky every NIC ships with a unique MAC address usually. I tried to find the thread I remember where a guy actually had two motherboards with the same MAC address but couldn’t find it. But it’s here somewhere, yes, two motherboards had the same MAC. Yes, he got a free replacement for one of them if I recall.

@robtitian16 Inside of fog.postdownload, add some debugging:

#!/bin/sh
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
#. ${postdownpath}<SCRIPTNAME>

echo ""
echo "postdownpath=${postdownpath}"
echo "Directory listing for postdownpath:"
ls -laht $postdownpath

. ${postdownpath}fog.postdrivers
. ${postdownpath}fog.postclient

I just double checked, and the bitlocker detecting functionality was introduced with this commit in working-branch: https://github.com/FOGProject/fogproject/commit/352ab6d0883ffb3deb96c135e83da06e22717328 and those changes are not present in the current dev branch: https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh#L255

So you’re misreading the version, or reading it from the wrong server or something else is going on that I don’t know about. It could be that the version label is just messed up in working-branch.

@george1421 said in Can't create image:

If you shutdown a windows 10 image using the start menu option, the computer isn’t really shutdown, its in an enhanced sleep mode for fast boot up.

That’s all explained here: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

@themcv Did you transfer the correct certificate from the old fog server to the new one? I have steps outlined on how to do this here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG#If_old_server_was_FOG_1.3.0.2B There’s also these more generalized steps that describe the same process: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

@themcv Did you get this fixed?

I’ve seen this several times. When the write rate starts to slowly drop down to nothingness, that means that the transfer has actually stopped. It stopped the moment the speeds started gradually declining. The displayed write speed is just an average, not actual.

@msi said in Fog is stopping deploying at 56%:

it’s a non-master.

In such case, you could try deleting that image’s files on that node - which will cause replication to copy it back. Then see if it’s fixed.

Running through the Troubleshoot FTP article would of course work, but there’s an easier way now-a-days @Sebastian-Roth. The FOG Installer calls a PHP script that connects to the FOG Database and corrects the FTP password for the node it’s running on, based on the password set inside of /opt/fog/.fogsettings

In other words, one only needs to re-run the installer to correct this problem. That is - if your FOG Version is new enough.

Bitlocker?

@greg-plamondon check the output of the top command. Also, this article is written for load related problems: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Web_Interface#High_CPU_load_from_web_interface

@lebrun78 said in Manage scheduled task:

May be examples are lacking in the documentation ?

Help us write examples? Post them here.

@tim-reynolds said in Domain add error 2224:

“hostnamechanger unknown return code: 2224”

That’s not a fog client error, it’s a windows error (because the fog client often just passes any errors it hits along to you via the fog.log file). Knowing this, you can use Google to search for stuff like “Windows error 2224” And after having ran that search, you might find these things:

• https://msdn.microsoft.com/en-us/library/windows/desktop/aa370674(v=vs.85).aspx
• http://comphelp.org/guide/rename-computer-error-2224/

As well as: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

@stiger What version of FOG?