Last active 7 weeks ago
You can move the images from the directory on the old server to the new server. You then just need to login to the New CD and create a "new" image using the same name from the old server.
Your new server will then pick up the images which have been migrated.
So I can confirm that the script error seems unrelated - we have been performing multiple multicast deploys to increase the chance of seeing script errors and can confirm that speeds do not seem impacted after encountering a script error.
We are still seeing multicast speed problems though. We have a room of 57 PCs we are testing in (our site has a lot more, hence why we are keen to see multicast working well).
We perform multicasts of all PCs by testing in groups of 12-15 PCs or so, and see typical speeds around 6GB/min. We can also run simultaneous multicasts of the same numbers, and they each seem to see speeds slightly lower, but comparable.
Then we perform tests of the same PCs but in groups of around 40+ PCs and then encounter speeds of only 2-300MB/min.
Currently we are patching in a second room of around 55 PCs to see if we encounter the same thing.
Server operation still appears normal. Screenshot of resource usage attached.
In short - No. The server is not stressed at all, as it only has CD running on it. All resource usage and processes look to be behaving whilst deploying images.
Will do some more testing today, but the key thing so far appears to be the script failure. Once this has occurred, any future deployments seem to be slow. Will see if web publishing resolves it.
We seem to be having random speed issues with CD (now on 1.3.4). Server is Windows Server R2 2012, running windows DHCP (issues were also present on TFTP32 before switching).
Have a group of 12 PCs and attempt to multicast and get only 20MB/s when deploying. Restart the whole server, and get 6GB/s using the same group, switches etc.
In further testing, we seem to also encounter random issues downloading core scripts. Either manually restarting or waiting for the PC to automatically restart allows the PC to get the script fine.
We are still troubleshooting to find a definite pattern, but if we seem to encounter a script download problem, we appear to get poor speeds from the subsequent multicast attempt.
The quantity of PCs seems to be irrelevant, however we seem to be more likely to hit a script error with larger numbers, which may be an issue or just chance.
Any ideas? Happy to provide logs etc if you can point me to what you need.
Script error text is:
Downloading Core Scripts
Could not download script
Response code 500.
We seem to be getting this exact error when attempting to group multicast to any more than 20 clients. Is there some form of client limit set somewhere that we can change?
Firstly, we discovered Clonedeploy a few days ago when looking for a better alternative to our ageing Ghost solution and we are pretty impressed with it!
We are starting to configure our environment now, but we have hit an unusual problem(?).
Under Admin>Security we have all login options set to "NO" as we run a segregated imaging environment. If we do an On Demand task etc, all works well and we do not need to intervene and login.
Due to the number of PCs though, we are now using Groups and multicasting. We Add the PCs to the group, set the image and profile etc and begin the group multicast. The PCs boot and detect an active multicast task, but immediately ask for a login.
What have we missed?
Our intention is that we can start these PCs and have them automatically start the multicast tasks unattended. We will also be looking for a way to wake all of the selected PCs via WOL in the future as this is a remote site.