check BIOS for multiple windows boot manager entries this could potentially be adding to the issue?
for example:
![](/uploads/profile/uid-29/29-profileimg.png)
Best posts made by Lee Rowlett
-
RE: Issues with Windows Boot Manager
-
RE: upgrade Debian 11 to 12
@Sebastian-Roth Done
I haven’t had chance to look into it any further but it’s the initial bind function that fails.
-
RE: Access Control Plugin
@Greg-Plamondon apologies i thought this was part of main code.
save below code in /var/www/html/fog/lib/hooks/removehosteditgen.hook.php
this is just to get you going, change data and template number to the right id that is relevent for what you want to remove and remove/comment out what you don’t want removing. read up about hooks on wiki. if you get stuck i’ll happily assist when i can to meet what you originally asked for etc but it’s worth you having a go yourself to understand how hooks function.
hope this helps
<?php class removehosteditgen extends Hook { public $name = 'removehosteditgen'; public $description = 'Remove unused fields in host edit general'; public $author = 'Rowlett'; public $active = true; public function __construct() { parent::__construct(); self::$HookManager ->register( 'HOST_EDIT_GEN', array( $this, 'hostData' ) ) ->register( 'SUB_MENULINK_DATA', array( $this, 'RemoveSideNotes' ) ) ->register( 'SUB_MENULINK_DATA', array( $this, 'RemoveDelete' ) ); } public function HostData($arguments) { if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) { unset($arguments['data'][5],$arguments['template'][5]); unset($arguments['data'][8],$arguments['template'][8]); unset($arguments['data'][9],$arguments['template'][9]); unset($arguments['data'][10],$arguments['template'][10]); unset($arguments['data'][11],$arguments['template'][11]); } } public function RemoveSideNotes($arguments) { if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) { unset($arguments['notes']['Host']); unset($arguments['notes']['MAC']); unset($arguments['notes']['Image']); unset($arguments['notes']['O/S']); unset($arguments['notes']['Last Deployed']); unset($arguments['notes']['Primary Group']); } } public function RemoveDelete($arguments) { if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) { if (!in_array(self::$FOGUser->get('type'),array(0))) { unset($arguments['submenu']['?node=host&sub=membership&id='.$_REQUEST['id']]); unset($arguments['submenu']['?node=host&sub=delete&id='.$_REQUEST['id']]); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-printers']); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-service']); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-powermanagement']); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-virus-history']); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']); unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']); } } } }
-
RE: Better OU Management
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')); }
-
RE: Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)
Hi Gregg,
What version of fog are you using?
-
RE: Extend LDAP plugin to support AD authentication
what issues are you having with the hooks? @george1421? happy to assist where possible
-
RE: Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)
@Raj-G If you just put the executables in folder /fog/MapFiles they will just copy to root the of the imaged machine.
all the fog.snapins script does it put things in place, set which node to use and which snapin to run.
you’ll need to write the script to actually run and execute the installers etc… (setupcomplete.cmd)
if you are unsure or uncomfortable scripting, you may be better off with the FOG client doing all the work for you, it’s very stable and much better going forward to maintain your image.
this script/scenario is best suited if you already have another solution managing your clients but you want fog to handle the initial imaging. otherwise FOG Client is defo your friend
-
RE: File Injection (possibly through Snapin management)
your config copy scenario you could do with postscripts using snapcheck.php and the concept would be: if cisco anyconnect client snapin is queued to be installed on the pc, copy config" that way if you need to update config file, just copy new version to server and next time cisco anyconnect client is installed so will the new config.
however if you’re looking to use fog + fog client to update existing config files you’ll need to write a script/snapin
i use postscripts + setupcomplete.cmd for our builds solely on the basis we have another system that manages deployed machines and fog to build and the setupcomplete.cmd purely for the fact it runs interactively outside a profile as we have unattended builds remotely and that way can have a “progress” indication without having to have an admin profile potentially accessible…
but i highly highly recommend the FOG Client as the developer works hard on getting it to be awesome, which it is and fits the build for practically every environment!
-
RE: Location Plugin - enhancement of behavior
yeah this was an improvement me and tom discussed several times in the past to improve the location plugin and remove the need for “manual” location selection but was going to save the implementation for FOG2.
However, i’d welcome the enhancement - unfortunately i don’t have anytime at the moment due to work/personal commitments to dedicate to it but as Seb said, would be fairly easy to implement.
i’d recommend making sure we implement being able to add multiple CIDR addresses to a location.
this would certainly remove the “User Error” in choosing incorrect locations or forgetting to change location when kits moved killing the WAN links and contradicting the whole reason for location plugin… not that, that ever happens of course rolls eyes lol
-
RE: Location Plugin - enhancement of behavior
@wayne-workman big multi-floor offices where the infrastructure is a scope per floor
Head Office:
ground floor - 192.168.0.0/24
first floor - 192.168.1.0/24
second floor - 192.168.2.0/24
third floor - 192.168.3.0/24
fourth floor - 192.168.4.0/24and so on… and only requires one storage node/Location to cater for the imaging demand.
otherwise you’d have to do Location per CIDR…obviously this would be few and fair between but it’s worth considering…
also another scenario would be
Location A:
Mobile Devices: 192.168.10.0/24
Desktop Devices: 192.168.11.0/24 -
RE: Location Plugin - enhancement of behavior
Nice one! having to setup additional locations per CIDR is no biggy really as this will automate the selection anyhow! So shouldn’t be too much of a change for people to get their heads around and most setups will work without the need of additional locations and is really the only caveat we’d need to make users aware of.
so all that’s left to do is edit
locationmanagementpage.class.php to include CIDR field and then the changeitems.hook.php storagenode functions are going to need rewriting - that’s probably the best place to include the CIDR enhancement.nice start wayne