Best posts made by Wayne Workman

Without using any shares, this is possible with FOG SnapinPacks. Here’s the article on snapinpacks: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

To summarize snapinpacks, you zip up the files you need along with an executable (like a script) and then upload that .zip file as a snapinpack. The snapin pack would then get deployed and the fog client would extract it and run the executable.

To give more specific help, I’d need more specific details. Like:

• What files?
• Where are they going?

@sudburr It’s just a simple realm command to deny all, then another realm command to allow a specific security group. What you are trying to do is not only possible, but a typical industry practice.
Here’s a snippit:

#Locking down who can log in from the domain.
#Block everyone:
realm deny -R domainname.com -a

#permit a specific group
# Security group needs made in Active Directory first.
#MUST BE domain local type group.

#SYNTAX:
#realm permit -R full.domain.name -g group_name_here full.domain.name\group_name_here
#To add group securitygroupname as able to log in:

realm permit -R domainname.com -g securitygroupname

####To remove if necessary:  
realm permit --withdraw domainname.com -g securitygroupname

Apologies - it slipped my mind. Of course @Testers are invited.

I wish there was a @Everyone or @Community tag lol. Or the ability to send out a message or email to every registered user lol!

Saturday because - when I’m at work I need to be working or at least able to work at a moment’s notice. I also want to give the hangout my full attention and don’t want to be distracted. I’m sure I’m not the only one.

@anthonyglamis yes.

I like this idea.

Last checkin date (if any)
and three statuses: No Client, Attempting Checkin, and Client working.

The statuses would come from if the client authenticates successfully or not. An attempt would at least let you know it’s trying.

This stuff can be two extra columns in the hosts database. last checkin date and fog client status. Those two extra things can be displayed in “List all hosts” and sorted.

@Tom-Elliott I’m not pressing hard saying we need this, I’m just saying it would be pretty nice.

@x23piracy said in Restored MBR Image over UEFI PXE doesn't boot:

Sure, that works but i want a working state whatever pxe was initiated from (legacy or uefi). What are the differences or the requirements to boot between legacy or uefi partition layout or bootmanager settings?

There are a lot of differences - and taking an image in one mode and deploying it in another mode will never go well.

If you want your final product to be in UEFI mode, then that image needs built on a computer that’s already in UEFI mode.

If you want your final product to be in Legacy mode, then that image needs built on a computer that’s already in Legacy mode.

@Shenanigan88 said in Where are you located ? Please Reply..:

Wayne, Oklahoma, USA

Woot woot!

@anthonyglamis said:

I figured who cares if I capture an image of a computer already joined to my domain as the client service would rename a unique identifier as well as host name of my choice.

I’d very strongly recommend against that.

Not because what the fog client does isn’t sound or anything… but because…

You’re image is now dirty. Any custom settings that were applied to that computer for that particular OU, and any particular user that logged onto that computer… those are ON your image. IF that image is later renamed/rejoined on another piece of hardware, those settings float to that next system if those specific settings are not explicitly undone by the next set of policies… and then the next, and the next.

And - maybe your Active Directory setup doesn’t set any settings on clients… but my setup does. A lot of settings, in fact. Settings that are specific and unique to the individual OUs that computers are placed in. Specific policies, specific pieces of deployed software. I look after 500+ computers and I rely on AD to work, on policy to work as expected, and I cannot go around doing these things by hand on all the hosts.

The images I upload - They have never been on any domain, they have never visited www.google.com or www.microsoft.com. I bring all software in via LAN or flash drive. All updates from our WSUS service. Chrome has never been signed into, nor firefox. My images are 100% built from scratch, nothing but vanilla windows. I never install the bloatware that comes with driver downloads - I extract the driver files themselves and install them using the integrated Windows method manually. My images are absolutely 100% pure. Because of this, I can download my image at any point and just update it - and I still have a very pure image.

If you’re system has already been on a domain and has been dirtied, it’ll always be dirty. It’ll always have settings and behaviors that you might not expect. And you’re just asking for complications down the road regarding these things.

The new FOG Client feature to unjoin/rename/rejoin is intended for host renaming to be super smooth. Even if that permits an image that is already domain-joined to be uploaded and deployed without issue - it’s just really bad practice to do this.

VMware Horizon View is a VDI solution, fog is not this. Vcenter is VMware’s proprietary centralized management point for ESXi hosts, fog cannot replace this, and does not do the same thing.

VMware is infrastructure for virtualized environments.

FOG is infrastructure for cloning OSs, and has some capabilities for management of OSs.

At home, I do all of my virtualization using various Linux distributions as hosts with libvirtd installed on them - and I use virt-manager to do easy & simple GUI management - but often times I do migrations from one host to another via CLI, or snapshots or automated tasks via CLI.

There’s also something called XenServer, which is open source & free and has many of the features that VMware has.

VMware’s backend is Linux and it uses many open source components - but VMware probably has a more polished proprietary GUI & management, whereas the others need a little more manual work and without sound Linux skills you would have a hard time with that.

Myself and others have a suspicion that Microsoft’s Hyper-V runs a Linux instance in order to accomplish virtualization in Windows due to the match-up of feature sets along with… the windows kernel just not being capable.

Both search boxes work the same, but the column search box only searches the results already displayed. If the main search is displaying everything when you type “3132”, this means that number is in all hosts somewhere. It could be a bios version, chassis version, bios date, no idea. Open up the inventory of one of these hosts and use Ctrl+F to search for 3132 and see what it finds.

Version of FOG, boot file being used, OS being captured, model of problematic host, Kernel version being used with fog, HDD type, and any other details would greatly help us help you.

@anthonyglamis said:

Once I determine that capturing and deploying is stable I will perform my own write up.

Good documentation is a vital part of any software solution - open source or not.

So is a helpful and acive forums

@x23piracy said in Migrate custom client banner image in filesystem when updating:

I think you are going to extend the fog install script for it?

Yep, probably by one line.

@x23piracy Good one but I would have quoted this one

https://forums.fogproject.org/topic/9498/reclaim-used-disk-space-on-fog-server/2

It would be nice if the SVN number and the FOG Trunk number matched again.

@boeleke All I can say is try it and see.

To explain the problem in more detail, when your sysprep stuff is happening after deployment, the fog client starts up and does it’s thing too (rename, reboot, etc.), and breaks the unattend.xml and setup complete stuff. The simple answer is just to disable the service before taking the image, and set up your golden machine so that it re-enables the service after all your stuff is done.

Also - it’s not a bug. The FOG Client is designed to do it’s job.

@jj-fullmer I’m writing a fog-cli using Python3, which can run on any OS. You’re of course welcome to keep going down the powershell path, but for the Python3 based project your talents would certainly be appreciated and your welcome to help.

@sebastian-roth We should have renamed that user donotusethisuserever

I remoted in with TeamViewer and figured out why it was redirecting to that /static/index.html page.

There were two nodes configured (incorrect in this particular scenario), one pointing to the fog server, another to the iSCSI device’s IP.

So, in FOG Configuration, it’s written to report the kernel and other info on all attached nodes. A web query was being made to that second (incorrect) storage node, and the NAS was redirecting to the aforementioned page.

Since iSCSI is a block device, and mounts like a local HDD, the secondary node was incorrect.

After deleting that incorrect node, all started working fine, and the main server which has the iSCSI device mounted as a local HDD is correctly displaying the available space on the dashboard so all should be fine now.

Tom had hinted at this, and that’s what I was looking for. Storage Management was literally the last place I looked for problems (of course). I actually ran a WireShark capture during the redirect and figured out the server was talking to the iSCSI device’'s IP via port 80, and that led me to find the issue.

@Quazz I’m sure Arrowhead wrote this for Pro/Enterprise. Makes sense.