1 of 1 people found this helpful
We have several customers with international deployments and with branch offices in countries like China, Brasil etc. (with high latency, low bandwidth and unreliable connections). This does work...
You do need a depot in each location and typcially a Management Point with OSD Proxy, Distribution Service and a Relay Proxy. The clients communicate to the central BLS via the Relay Proxy. This is http-traffic and the http protocol is designed for those environments (with high timeout values etc.). The mass data of the packages is retrieved from the local depot, and this local depot is "filled" from the upstream depot through the local Distribution Service (which ensures via bandwidht-aware replication, checksums etc., that the packages aren't corrupted on the transport).
So, yes - DSM is definitely an enterprise scale and enterprise ready system that serves several of our global customers :-)
Thank you for sharing.
I am waiting on my SME to respond however meanwhile I recall the issue was related to the SQL database (at HQ) and ??profiling?? being the issue.
We have a local depot which took quite a while to synchronise but got there in the end.
Laptops take anywhere from 12-36 hours to build.
Is there a solution to resolve the SQL issue?
from a DSM infrastructure perspective (BLS <-> SQL) it doesn't make a difference if you have a remote client connecting or a client-system in the headquarter. So you see almost the same build-times, as long as all required packages are distributed to the local depot. If you are having a SQL issue - which I don't know - but if you do, then all clients should be concerned. Cannot say more at the moment, especialliy not, what or how to fix...
Additionally, I don't really know what you mean with profiling? Maybe some roaming profile issues or so - this could be the case, but one would have to know way more to identify any issues and how to resolve the corresponding problems.
Anyway: build times from 12-36 hours are not in any normal timeframe. I'd say, anything above 3-4 hours is too much and you should have build times at 1 hour max. in an optimized environment (with individual reference image for example)...
I can't thank you enough for jumping in and sharing your knowledge.
I am at a little disadvantage as I'm not familiar with DSM and am relying on my HQ IT team for info.
I will try to extract the true issue from them this week. Locally my team have no access to any of their systems so unable to deeply analyse the true problem, logs, configuration etc.
Your information is immensly helpful- thank you.
having no access to the systems and logfiels is not really helpful when bugfixing :-)
Just to give you a little information on how the build actually works.
- A client will boot with a PXE broadcast that hopefully will be received by the DSM "OSD Proxy" component.
- The OSD Proxy will check with the BLS (Business Logic Server) if there is a pending OS Installation for this client. (The BLS is the only component that accesses the DSM database, so this is why Frank mentioned that any database related issues muss affect all clients in all locations). The BLS is located in the HQ near the database (usually).
- In case of a pending OS installation has been found, the OSD Proxy will send the Bootenvironment (Windows PE).
- Usually, the client then will boot with Windows PE and access the Windows Sources in the depot to run the setup.
Bad news here: as the new client does not exists yet, the OSD Proxy acts as a "representative" for the client, and the OSD Proxies depot will be used.
From my perspective, the major question you should ask your HQ IT team is: "Do we have an OSD Proxy in our location?"
It appears to me that the answer will be "No".
In this case, the client will have to pull the Windows PE and the OS sources from the depot where the OSD Proxy is assigned to (most likely the HQ). This behavior can be configured, of course.
If there was an OSD Proxy in your location, here is still some communication necessary between the OSD Proxy and the BLS, but as Frank already has mentioned this does not explain thaat long build duration.
Thanks for your input Axel.
i have received more information:
Our DSM environment is configured to work over http and BLS is responsible for all database actions. So ideally the management point has a depot (files) and is responsible for OSD proxy, Distribution, DSM Remote and a couple of other roles.
When there’s a high network latency, at times remote connection between BLS and MP will timeout. This will surely cause delay in image deployment. We can increase timeouts but that may not give us the desired result.
If I can suggest then I would include BLS in Australia DSM Server. This should resolve the issue. I am not sure about the licensing part.
this is the Standard Configuration.
On a MP (Management Point) you can install several Addons like OSD. This are the active components of the system.
And on the Depot Server there are all the files you need for your Installation of Operating System and the other software. This is distributed from the master depot to your Depot Server.
If you have a bad Connection between the BLS and your MP Server you should have installed the "Relay Proxy" on your MP. The information transfer between your MP and the BLS is done over HTTP and are only some small packages. This is not the reason why your installation need this long time.
What need the long Time? The Installation of the OS or the rest afterwards?
Hmm, I think this situation requires a non-technical response, too.
From my point of view the IT department that is responsible for running DSM should reach out to their HEAT partner to get support on the issue.
I guess this is not a bandwidth or latency problem but the system needs to be properly configured to ensure that all packages are available and drawn from the local depot.
But guessing is not the right thing to do in this situation.
Somebody needs to analyze the problem and then fix it.
Just my 2ct...
i agree 100%. And this is my crusade. The tail wagging the dog so to speak.
To date the only proposal was bandwidth via high cost MPLS links.
this answer of your HQ IT honestlyis not really helpful.
- Even if there is a (technical) possibility to add a BLS to a remote location, this is neither recommended nor offficially supported. All BLS Servers should be located in the central location where the database also is located.
- So, adding the BLS component will not work (and even if it worked it would rather make the situation worse).
- A latency between the BLS and the Management Point (MP) affects the "sync" between client (here: OSD Proxy as a representative for the client). This is not massive data, but in case of tmieouts there could be long installation durations observed.As soon as the setup starts, there is no sync until the end of the build.
- All packages (Windows PE, OS Sources or images, Installation packages) are downloaded from the (local) depot and are not affected by any connection issues to the HQ at all.
So, if there is an OSD Proxy in your location, it might be assigned to the wrong site. It still sounds to me as if the packaged are downloaded from a wrong depot. But this is all poking around in the dark. Youur central IT needs t get this fixed.
Just another idea: maybe there are a lot of patches following the OS installation, this could slow down a build as well.
that's ok, these components are installed on other servers, some of the listed components can only be installed onto one machine (e.g. Primary BLS, Patch Management Server).
The important Applications are OSD Proxy and Distribution Service, and these are installed.
As Klaus already has mentioned, best would be to reach out to a local DSM partner.
The next step will be to dig into the infrastructure configuration to answer questions like:
- Is the local Server in the same site as the clients?
- Is the Distribution Service assigned correctly to the site of your local server?
- are the depots assigned properly?
If you were able to log on to the local DSM server you could run nimoni.exe (just use Windows+R and type nimoni). This will give you some information on the site and the depot the server uses. The "Server Share" should be the path \\youlocalserver\DSM$.
Then you could do the same on a client and compare the information.
But this seems to be an issue in the basic system config that we cannot solve here, I am afraid.