This has been added. You can delete tasks from the db after searching. Active tasks will be cancelled. Nice part is the checkboxes remain in their checked state even on subsequent updates. If you cancel it will first prompt. Hopefully this helps.

@Junkhacker said:

@Wayne-Workman I like the idea of snapin groups, but I’m not sure how it could be applied to tasking.

Well, the group would be “applied” but the group wouldn’t show up in “Task Management”, instead each individual snapin would show.

it’d just involve a loop somewhere internally to do a “single snapin task” for each snapin in the group - to each host the group is applied to… or a group of hosts…

I’m not sure how or where that would be done because I’m not familiar with FOG’s web code.

perhaps it’s time for a new version of fogprep
one that will allow you to selectively do some of the things a sysprep would do for you, but without the parts you don’t want

I have created a plugin to allow people to change the task types as they see fit.

I did this for two reasons. First, I don’t find the current states that hard to follow. When it comes to tasks the POV is always from the client/host. So download means the client is pulling from the server and upload means to push to the server. The hosts, after all, are the items that get tasked. I have had this discussion multiple times in the past and I still stand strong that they’re fine the way they are. That said the plugin allows the admins to use whatever terminology they deem necessary.

The second reason is to allow the admins to make the tasks as they see fit. For example, make a currently advanced task non advanced so it displays in the main task list. Or adjust the tasks to be shown on only group or host where they are currently shown on both. Ultimately this plugin allows the admins to create/edit the tasks as they see fit.

32-bit and 64-bit both work in the inits.

You just have to boot into debug mode right now and then type in the above commands. I will talk with Tom to see if we can change the compatibility check first as we do not want to mess up the current flow

Just tested this feature with a Synology NAS, works beautifully. Job well done.

@PaulTR

You can do this already with the location plugin. If your three sites are internet connected and have domain names or static IPs, then you need to just allow traffic from each site to each other site through the Firewall for FTP and HTTP and HTTPS, and then you could drill down further by setting up port forwarding if you wanted, or have sub domain names and configure DNS to take care of the Name to IP resolution.

If you build a storage node for each physical site, and put all three in the same storage group, and make one of them the master storage node (the one that receives all uploads), then all storage nodes should then replicate images - and you’d be using one single Fog Console instead of three.

Move to Feature Request

you could also set variables at registration stage in autoregister in the sense of if you know which OU a machine should go in by it’s naming convention (or by location if using location plugin) you could set it there and it gets set during registration then you never need to think about it and if it doesn’t match criteria revert back to defaultOU field… this potentially could be bundled into a simple plugin to hand OU … the limit really is endless (and i’m sure this code could be cleaned up a lot (Tom’d) and it’s quick and dirty but just so it’s simpler to follow…
for example:

if($_REQUEST['doad'] == '1') { //Room/Location 1 Example Handler $r1chk = strpos($realhost, 'R1-'); if ($r1chk !== false) { $r1 = "1"; } //Room/Location 2 Example Handler $r2chk = strpos($realhost, 'R2-'); if ($r2chk !== false) { $r2 = "1"; } //Room/Location 3 Example Handler $r3chk = strpos($realhost, 'R3-'); if ($r3chk !== false) { $r3 = "1"; } //Room/Location 4 Example Handler etc...etc... $r4chk = strpos($realhost, 'R4-'); if ($r4chk !== false) { $r4 = "1"; } if ($reallocid == "10" && $r1 != "1" && $r2 != "1" && $r3 != "1" && $r4 != "1") { $OUs = "OU=Location10,OU=Workstations,OU=Domain,DC=com"; } else if if ($reallocid == "15" && $r1 != "1" && $r2 != "1" && $r3 != "1" && $r4 != "1") { $OUs = "OU=Location15,OU=Workstations,OU=Domain,DC=com"; } else if ($r1 == "1") { $OUs = "OU=Room1,OU=Workstations,OU=Domain,DC=com"; } else if ($r2 == "1") { $OUs = "OU=Room2,OU=Workstations,OU=Domain,DC=com"; } else if ($r3 == "1") { $OUs = "OU=Room3,OU=Workstations,OU=Domain,DC=com"; } else if ($r4 == "1") { $OUs = "OU=Room4,OU=Workstations,OU=Domain,DC=com"; } else { $OUs = explode('|',$FOGCore->getSetting('FOG_AD_DEFAULT_OU')); }

Bumping this thread… Running into the multiple domain thing again at work…

Just read through Tom’s reply… seems sorta confusing but I’ll give it a shot but I don’t think it will work.

Two or more domains in one environment also means two or more users / passwords for domain joining in an environment…

@Jean-Jacques-Morda Group Description … notes…

I would agree.

Any task, be it on a registered or un-registered machine, should show up in the web console as an active task and show in the task list.

@Tom-Elliott said:

All other pages still redirect to edit page. This is because there’s more likely a need to edit the element after creating it. However, I do agree that creating users should not need this level of action, as you have the exact same choices in edit or add.

Hopefully you don’t mind.

The Username field is pre-populated with the last entered username, this is to be expected as if you make a mistake somewhere, rather than have to start ALL over, it puts the original value back. This still holds true even on successful create.

I just read this and it’s not very clear.

I added what you suggested. The User page now goes to “add”, rather than editing the user you just created.

Yes, that was this option help me to find out how to deactivate it… but, my request was to avoid deactivate for all, just for computers that are bugging with that. All of mine this case but i certainly will have the case that some will works and others not. A by group WOL activation should be really cool.

don’t get me wrong. we know how to script installs / use GPO.
just some items are just not worth the work at the moment.

You lost me at “pass the write flags around…” I don’t currently have the knowledge to even know how to start with this. Would you be willing to provide a solution for this even though you’re not a fan of the idea? This feature would give me and other service shops a huge increase in speed and flexibility when backing up random client’s computers as they arrive for service. With Fog already as powerful as it is, this is the only request I constantly get from technicians and other shops we’ve introduced to Fog.

Figured it out.

goto ${username} || goto MENU :fogUser menu item --gap -- ---------------- Welcome fogUser ---------------- item return return to previous menu item kav Kaspersky Antivirus choose --default return target && goto ${target} :fogTech item --gap -- ---------------- Welcome fogTech ---------------- item return return to previous menu item Clonezilla Clonezilla ISO item UBCD Ultimate Boot CD item Hirens Hiren's Boot CD item kav Kaspersky Antivirus choose --default return target && goto ${target} :MENU menu item --gap -- ---------------- iPXE boot menu ---------------- item return return to previous menu choose --default return target && goto ${target}

Then just define the functions below the menu. fogTech and fogUser being different users that the menu accounts for and MENU being the default menu.

This was made apparent after looking at the advanced.php code presented here https://wiki.fogproject.org/wiki/index.php/Advanced_Boot_Menu_Configuration_options

Access to this menu can be granted without granting that user rights to the website by clicking the “Mobile/Quick Image Access Only?” toggle when creating the user.