Topics created by Piplup

@Piplup said in Proofread concept:

I discarded the VLAN idea because it’s too late to implement safely now for me.
You’re right - there is 1 L3 10 Gigabit Switch and A lot of L2 1 Gigabit Switches
My question was, is a network as described with the network plan I provided realistic?

I worried that because everything is in one LAN (192.168.5.0/24), and the ISP router is effectively the DHCP Server, that this may lead to broadcast storming or other fatal performance loss in the network because every Client has a dynamic IP.

No worries for the number of hosts. With tcpip there is not really an issue with broadcast storms. If you are using an old lan technology like netbeui, spx, or banyan vines then broadcasts would be a concern. With TCP the main type of broadcast are ARP messaging (in general).

Regarding the HDD - it’s supposed to be 2 SAS HDD’s in RAID 1, because these are the only harddrives in the paper server. So effectively 1 HDD. I know 200 Mbit’s is much, I’m still debating in changing it to 2 SSD’s. I was just worried they would break faster.

One HDD or 2 in Raid-1 same difference since only one is the leader disk an the other is the mirror or follower disk. If you are using a traditional RAID controller then the onboard cache memory will help a bit with performance. But remember you are dealing with multi GB files for imaging so the cache will only help so much. In regards to SSDs, for FOG imaging they will not break faster than HDD. What breaks SSDs is many writing to the drive. In the case of standard fog imaging its a write once, deploy (read) many times. SSDs are ideally suited for FOG imaging. I would say the HDD would have a shorter life because of the head thrashing about the disk when you have multiple imaging going on at the same time.

Last thing regarding the Bottleneck … So, the image server cannot deploy faster than his own read speed and the write speed of the Client, right?

Here are actually the bottlenecks in imaging. Lets assume a deployment here server->client

FOG Server disk to network Network infrastructure Network to fog imaging Fog imaging to disk

In the case of a FOG deployment, the fog server does very minimal work. On the FOG server it only moves data from the disk storage to the network adapter and then manages the overall progress of imaging. If you wanted to you could run the FOG server on a Raspberry PI 4 server. The key is getting a fast data path from disk to the network.

For fog imaging the target computer does all of the work. The target computer takes in the image from the network, decompresses the image dynamically, and then writes the image to the local hard drive on the target computer. So impacts on deployment speed is network, CPU (Ghz and number of cores), memory speed, and local storage drive.

So if you were to setup FOG and deploy to a computer the program that writes the image to disk is called PartClone. PartClone gives a performance number. This is usually in GB/min. This number is actually a composite number that indicates how fast Partclone can write the image to disk. But behind that number is all of the defined bottlenecks. Lets say you take 2 computers one is a 2010 Core2 Duo with a HDD and the second is a 2019 Quad Core with an NVMe drive. Using that same FOG server the Core2 computer will probably deploy in the 4GB/m range (bottleneck is CPU or local HDD). Where that Quad Core with NVMe drive will deploy in the 6.5GB/min range (bottle neck is the 1GbE network)

@Piplup said in Need urgent help on joining a domain automatically after installation:

Thank you, but Christ, that’s a lot.

Its not bad if you build it up, start with the basics and add on.

I’d create an InstallUser for the AD with limited rights, which will be automatically joined to the Domain via a fixed entry in the “unattend.xml”. (?) Software will already come preinstalled with the image. From there on, the User manually Signs Out and Signs In via his given AD credentials.

Yes that is how we do it. Here is an example of an sanitized version of our unattend.xml. https://forums.fogproject.org/post/87392 The point of the tutorial link I provided before was to show you if you have text in your unattend.xml file you can “tweak” it at deploy time. Its really NOT that hard. The bit I didn’t show you was the complete working model: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed This is the full working postinstall script it does more than what you need at the moment. The script you are interested in is fog.updateunattend

Doesn’t an Active Directory Domain join require Administrator privileges from the Domain Controller in the first place? Wouldn’t I just create a security vulnerability…? If you have experience in this, please share your advice.

Yes and no. Yes you need an elevated account but you can restrict that account to only add computer to ou. Its been a while since I set that up but I know with advanced acls you can restrict that account to only the task at hand. Also if you use the WAIK toolkit you can encrypt the password in the unattend.xml file so it can’t be hacked easily. Lastly in your setupcomplete.cmd batch file, you will have that nuke any unattend.xml file or another other setup files that are used during OOBE/WinSetup.