@The-Dealman Awesome thank you! and we did publish 1754 specifically due to this issue (manually running the automated processes just in case your org is worried at all 🙂 )

@sebastian-roth You correct, I just used the file of that new kernel and it worked.

@MikeBC I agree. In our imaging lab we are only using wd15 docks the wd19 even after the dock firmware upgrade were just to unreliable reporting to the firmware as pxe compliant. So in the end we moved the wd19 docks to the user’s desk and acquired their wd15 docks for the imaging labs.

Sorry if me message there sounded short, that was not my intention. I simply wanted to inform you of the plugin that would do exactly what you were asking.

There is some documentation on how to use the location plugin too, for the future.

Mind you, you can do this is “Central GUI Server->Storage Nodes about” layout, or really however you feel appropriate for your environment.

Location plugin will likely get an overhaul in the next few years (yes years) with more automating of how to select which storage node’s based on subnets/ip ranges, but for now it’s completely manual (and thus extremely granular too).

https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@Fernando-Gietz Okay I got it working. You guys are awesome keep it up!

@george1421 Yeah it looks like by adding this to the xml file cscript /B C:\windows\system32_slmgr.vbs /ato resolved it on my machines. Thanks for the help.

@The-Dealman As George said, take a look at the logs to see the current status of replication going. It replicates image by image but kind of parallel to all storage nodes.The actual replication of one image to one storage node is started as a background job and so it is mostly going all in parallel.

@Wayne-Workman Okay i’ll give that shot on monday

Noted. This makes sense.

@sebastian-roth It’s working now.

After I update the version of FOG I was able to image the 7240’s without issue. So issue is solved.

I gotta pipe in here that we’ve standardized on “ubuntu-14.04.1-server-amd64” and SVN 2332 and have managed to slay all dragons thus far.

It works if the master node is the same as the fog server right?

In SVN I’ve fixed this so the bandwidth shows for the selected node from the graph of disk usage.

[quote=“Tom Elliott, post: 24175, member: 7271”]That’s more advanced than I know at this point.[/quote]

ah i see…ok no worries then.

That’s what [url=https://www.sbobet168.com/]sbobet[/url] it took to get mine to image.

I figured it out, i had to disable the encryption before imaging.

I actually found my answer here [URL=‘http://fogproject.org/forum/threads/dell-2330-all-in-one-network-issue.1054/#post-9005’]http://fogproject.org/forum/threads/dell-2330-all-in-one-network-issue.1054/#post-9005 works great[/URL]

I’m using 0.32 and must be missing a step with Capone. I followed the instructions in the wiki. I pasted the capone text in the pxe menu but it didn’t show up. I was able to do enough reading and modified the default file to include a Capone option. I get an error saying that the OS type couldn’t be determined. Any suggestions?

After doing some more testing i found that i get this error on Seagate Barracuda ST3250312AS drives which have the 4k advance format (Note: there is something also called Western Digital Advanced Format and Dell Advanced Format) From my testing it seems Windows Vista or Windows 7, disk alignment is correctly forced by the OS and for windows xp you will need to create an image on for this drive type Align the disk with an alignment tool (For example the Paragon Alignment Tool, a third party product, has been used by many) then Sysprep the image. The release of 0.33 fog should resolve this when ever released. Microsoft has also developed a patch for this [URL=‘http://support.microsoft.com/kb/982018’]here http://support.microsoft.com/kb/982018 [/URL]