Connecting from VEEAM Monitor client to remote server

[shija03]

I have Monitor server and client (2 different physical servers). Neither of them under a domain, neither of them under the same user and password. How can I connect the client to the server?

The service indicates to be connected, but the database to <sesrver>\VEEAM database is disconnected - how could I make them connect without having to be in a domain, nor having to share the same user/password?

I tried creating a trusted environment ( IPC$ mapping between the two systems - client mapping a drive from the server), but no luck. Is there a way to specify the connection to the server? Any files, registry, anything besides simply specifying the server IP address?

Thank you,

James.

[IanRLowe]

"me too".

I'm loving Veeam monitor on our ESX environment - but I don't want to only be able to monitor it from inside the domain where our application is hosted - I would much prefer to run the Monitor on my workstation, in our office domain, and connect to the Veeam collector/database inside the hosting domain...

but it doesn't seem to do this, no matter how many hoops I jump through. annoying, because this one failure renders the tool much less useful than it would otherwise be.

[Gostev]

I've checked with devs and QC and yes officially installations outside domain are only supported when client and server are located on the same computer. However one dev told me he was able to make this working via IPC$ mapping on previous version (3.0). We will try to do some testing of the upcoming 4.1 release in this scenario and hopefully will be able to provide some workaround for such deployments.

[shija03]

Would it be possible to obtain the details on how your developer was able to establish the DB connection using IPC$? I would very much would like to be able to use the application from client/server perspective rather than stand-alone.

Thank you,

James.

[Gostev]

James, I asked about that right away, but unfortunately he does not remember the details by now, and stated that he would need to start experimenting from scratch.

[shija03]

Hi Gostev,

Thanks for inquiring your developer about this. I would still think this is worth pursuing:

1- Customers like myself would enjoy the benefits of your client/server architecture.
2- The software could now add another listed feature in the documentation showing that there is not restrictions on how to do client/server (I don't use Domain controllers in order to avoid data centralization - hack me once get it all)

It's too bad that the developer may not do it, but if you say that the new release will have this feature, doesn't that also imply that he has to do it from scratch anyways? This exercise may be even productive towards the next release

Thank you,

James.

[Gostev]

James, just wanted to correctly set expectations - we do not have this feature planned for the upcoming release. We find that most typically customers who want to use client/server architecture all have Windows domain controllers. Customers without AD are typically very small and are not using remote SQL or client/server architecture anyway, instead installing everything on a single VM. Thus, adding complete support for client/server deployment without domain controllers has always been a very low priority for us comparing to other pending features.

But, I can promise you that while testing the next release we will attempt to find and publish some workaround for deployments like yours.

[shija03]

Gostev,

Understood - and I hope you find the workaround. When is the testing of the next release planned for?

[Gostev]

We are just about to start it

[shija03]

Any updates on this matter?

[Gostev]

James, we did some testing and unfortunately such deployment scenario will not be supported in the upcoming release - we could not find any workarounds. However, we will most likely address this issue with the next release, as a part of some other modifications around SQL interactions.

[shija03]

Gostev,

Thank you - I'm then looking forward for the next release - it is only logical to think that if you have a client with a DB behind, that it could/should be able to support client/server connectivity from remote systems. Thank you for all the assistance.

James.