Best posts made by Wayne Workman

Code 87 threads. I glanced through these, most are configuration issues - people not re-assigning settings to the individual hosts.

https://forums.fogproject.org/topic/3846/domain-join-not-working-since-moving-to-v1-2-0-error-87/4

https://forums.fogproject.org/topic/8341/the-parameter-is-incorrect-code-87

https://forums.fogproject.org/topic/1937/help-with-domain-joing

https://forums.fogproject.org/topic/5812/samba-domain-integration/61

https://forums.fogproject.org/topic/6879/i-can-t-join-machines-on-domain

https://forums.fogproject.org/topic/7126/hosts-unable-to-join-domain

https://forums.fogproject.org/topic/3140/domain-join-is-not-working-fog-server-1-1-1

@george1421 said in Dnsmasq bios and uefi:

also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

Wow…

@RipAU said in Apache2 for fog vhost - failed - Trying to update Trunk:

Would this help fix the issue at all with the upgrade?
https://forums.fogproject.org/topic/6975/change-server-but-not-change-certificate/6
From reading this I should be able to run this without affecting the currently running clients? as it should use the current CA?

Wouldn’t hurt to try, not at all. Here’s further reading on the topic for yourself and future readers: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

You should read this:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Also, sounds like you need to update the fog server too. 7981 is behind, we already have release candidates.

Kernel 4.8 now supports the keyboard for Surface Pro 3, and I am told that 4.7.5 added support for the Surface Pro 4 keyboard.

http://lkml.iu.edu/hypermail/linux/kernel/1607.3/02607.html

So this next FOG Kernel should relieve a lot of headaches and frustration with using USB keyboards and USB hubs and such with Surface Pros.

@Sebastian-Roth said in Fresh VM and Fog 1.2.0 install having issues with iPXE boot:

I always wanted to document the options needed and so I did just now: https://wiki.fogproject.org/wiki/index.php?title=IPXE#rom-o-matic.eu

+1,000

It’s strange that the admin account doesn’t have Internet access. Perhaps do network troubleshooting. First step is to check for loose or damaged patch cables. Next check for an IP address on the machine. 169.254.x.x indicates no dhcp lease recieved. If you have a good address, next ping the router (the gateway). If that succeeds, try to ping 8.8.8.8 which is google’s primary dns address. If that works, ping www.google.com. If you get this far and pinging google fails, you have a dns issue.

@gwhitfield said in Snapin Questions:

@Joe-Schmitt Alrighty then, I’ll work with that. Thanks!

It’s not perfect yet, but here is what we have so far:
https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

@arnaudrigole I’m sure. But you can build a storage node from windows without mounting anything from it to the fog server. Read through this:
https://wiki.fogproject.org/wiki/index.php?title=Windows_Storage_Node

Also look at Georges earlier post, it’s filled with good stuff.

@MattPayerle Alright, you asked a few questions and made some good points that I’ve also thought about in the past too.

The option to enforce should be a default IMO - @Tom-Elliott.

With the checkbox ticked, Yeah it would reboot to change the hostname whether anyone is logged in or not - and not give warning either because it’s being “Enforced”. This is not a half-hearted enforce, this is full-hearted enforcing, it gets it done. This is a good thing. If you want a computer’s name changed or joined to the domain - and you’re enforcing this, yes you’d absolutely want it to happen immediately whether people are logged in or not. Most cases, they will not be logged in though. You’d be imaging, or provisioning new computers, or be dealing with a specific issue where someone asked you to fix said thing - so they would expect you to be working on it.

Active directory settings are not required for hostname changing to be enforced. If you look at the picture I posted below, that’s for one of my test boxes at home. You see that the Active Directory fields are blank - because at the moment I don’t have a test domain setup at home. But I still use the enforce option in there.

I think the only improvement would be seen under high usage, like simultaneous unicast deployments. And even then, you’d only see that increase if you have more than a 1Gbps network link to the server. You’d need 10Gbps to see the difference, otherwise you will cap at 1Gbps which is already filled completely by mechanical drives with 3 simultaneous unicast deployments.

@Arrowhead-IT said in Quick Question re Changing Fog 1.2 IP address:

I think that if you just change the ip in the fog settings it might just take care of the rest for you.

This is true for a new install. For existing though, the IPs in the DB are not touched. This is by design.

@Tom-Elliott I would suggest moving this enforce checkbox to the computer’s general page, somewhere close to the hostname. It would be more sensible there. Or perhaps even the host’'s Service Settings page, this would also be a better fit. Because this feature doesn’t just deal with Active Directory, it deals with the hostname too. Having it on the Active Directory page is a little misleading because of this. And I’d suggest it being defaulted to on since people so often ask about problems that are due to this, and since it cannot be set during full host registration. It should just be on.

I’d also recommend new labeling for the checkbox. Something that specifically states exactly what it does, like:
Enforce hostname and Active Directory settings even when users are logged in?

I’d also suggest changing the legacy password field from what it is to:

Domain Password Legacy
(Must use FOG Crypt)

Would anyone be interested in a fog test for 1.3.0 when it’s released?

Why would you freshly install 0.32 ? Sorry but I can’t help you with that version. Please move to 1.2.0 or FOG Trunk preferably since this is a new installation. And use Ubuntu 14 or 15 please, or some other newer distribution.

We have ample guides to assist you with this in our Wiki.

@theBiggestRick We use a local account to build the image from scratch. From scratch meaning we format the drive - install all drivers ourselves, don’t include any terrible security-risk manufacturer bloatware. We optimize the image for the model and use it will be used for.

@mm-Ekimia In the 6 days that have passed, you could have already had this project done by just imaging one drive at a time in the actual computer it belongs in. Even with Norton Ghost, I’ve imaged 30 HDDs in a day that I had to physically remove from incompatible Laptops - image - and then re-install. And that was with handling all my other responsibilities and phone calls too.

Who cares if it takes 5 minutes for your “powerful skylake laptops” to pxe boot? FOG is free and open source and developed by volunteers, and supported by volunteers - and they don’t ask for a dime in return.

In the 5 minutes it takes one of your “powerful skylake laptops” to pxe boot, I would have another 10 hooked up by then and also waiting to pxe boot.

@george1421 I helped via join.me and we ended up using that single powershell command of yours to setup NFS correctly on windows.

New-NfsShare –Name "windowsNode" –Path E:\ –Authentication sys -AllowRootAccess $True -EnableUnmappedAccess $True –Permission Readwrite

@arnaudrigole says he will document every step with the windows storage node. I look forward to what he comes up with.

@Joe-Gill I found a way, but it uses a snapin that runs a small powershell script to do it. You can find that script in this thread: https://forums.fogproject.org/topic/8406/fog-client-printer-not-displaying

Let me know how it goes.

@RobTitian16 Because the two servers each have their own DB, one DB knows about the new upload, the other doesn’t.