VSPC sits above Veeam Backup & Replication and gives you one place to manage tenant onboarding, license distribution, usage reporting, billing data, and day-to-day monitoring across the customer environments you support. Without it, you end up doing too much by hand and logging into too many individual systems just to answer routine operational questions.

This article walks through a production VSPC deployment: how to think about the architecture, how to onboard tenants in the right order, how the Pulse integration changes license management, what usage reporting looks like when you need billing data every month, which dashboards actually matter, and where the REST API fits when you want to automate the repetitive parts.

Architecture and deployment

VSPC runs as a Windows application on its own server. It uses a SQL Server or PostgreSQL database, with PostgreSQL now serving as the default option. It does not manage tenant VBR servers by talking to them directly. Instead, it relies on the Veeam Management Agent.

That detail matters.

When a tenant enables the option to allow their VBR server to be managed by the service provider, the management agent is installed on that VBR server. From there, communication depends on where that VBR server lives. If the tenant VBR server is in the customer environment, the management agent connects outbound to the service provider cloud gateway over TCP 6180, which is the same port used by Cloud Connect. If the VBR server is hosted inside the service provider environment, the agent connects to the VSPC server over TCP 9999.

One port that people sometimes confuse here is TCP 9398. That is the VBR REST API port used by Enterprise Manager and other direct API consumers. It is not part of the VSPC management path.

From a design standpoint, VSPC and the Cloud Connect VBR server should stay separate. Both need to be reachable from tenant environments, but they should not be collapsed onto the same system just because a smaller deployment makes that tempting. Keeping them separate is the cleaner design and gives you more room to grow later. It also keeps a problem on one side from immediately becoming a problem on the other.

For sizing, the requirements are not extreme, but production reality still matters. Four cores and 8 GB of RAM may be enough to get started, but eight cores and 16 GB is a much more comfortable target for a live environment. PostgreSQL and the VSPC services both consume memory, and 8 GB starts to feel tight sooner than people expect. Disk is similar. A 100 GB OS disk may work, but 200 GB on SSD is the safer production call because logs add up. Network is less interesting here. VSPC traffic is management-plane traffic, not heavy backup traffic, so 1 GbE is generally fine.

For the database, local PostgreSQL may be enough for a small install, but remote PostgreSQL or SQL Server is the better production pattern. Treat the database like an actual service dependency, not an afterthought.

Tenant onboarding

The part that trips people up most often is not the wizard. It is the order.

In VSPC, tenant onboarding works best when you build the company relationship first, then map the Cloud Connect site, then handle the license. When you do it out of order, you can still get there, but you also create cleanup work that should not have existed in the first place.

Start by creating the Company record under Organizations > Companies. That is where the tenant identity begins. Add the company name, the contact details, and the reseller information if that applies in your model.

Once the Company record exists, move to the Sites tab for that company and add the Cloud Connect site. Select the Cloud Connect VBR server as the infrastructure source, then assign the existing Cloud Connect tenant account from VBR to that company. At that point VSPC can verify that the mapping is valid.

If the tenant also runs their own VBR server and you are going to manage it, that server has to be brought into the same picture. The tenant does that from their VBR console by opening the Service Provider wizard and enabling the option to let the VBR server be managed by the service provider. That step installs the Veeam Management Agent. On the next polling cycle, VSPC discovers it and ties it back to the correct company.

Only after that would I push the license.

One operational note that deserves to be written into every onboarding checklist: TLS inspection between VSPC and tenant VBR servers will break the management-agent connection. If a tenant has deep packet inspection happening at their edge, this is going to look like a Veeam problem until someone traces it back to the firewall. It is the same class of issue people run into with Cloud Connect gateways, so it is worth calling out before the first ticket lands.

Pulse integration and license management

This is where VSPC starts saving real time.

VCSP Pulse is the licensing system behind the ProPartner portal. That is where contracts live, where license keys are generated, and where usage reporting is ultimately submitted. Without integration, the workflow is exactly as annoying as you would expect: log into the portal, create or download the license, move the file around, get it to the tenant, and then chase down whether it was installed correctly.

With the Pulse plugin integrated into VSPC, that whole process gets cleaner.

You connect VSPC to Pulse under Configuration > Plugin Library > VSPC Pulse Portal, enter the Pulse credentials, and let VSPC sync the contract details. After that, license generation happens inside VSPC. On the tenant’s Company record, go to the License tab, click Generate, choose the product, set the workload count and expiration, and VSPC handles the rest. It creates the license in Pulse and pushes it to the tenant VBR server through the management agent.

That is the difference between a manual file exchange and an actual service-provider workflow.

You can also monitor license consumption directly from the Companies view. The Workloads column tells you how much the tenant has used against what they were allocated, which gives you early warning before someone runs into a hard limit.

At month end, usage reporting moves through the same stack. Under License Management > Usage Reports, you generate the monthly report and submit it through Pulse. The useful part is that VSPC has been collecting the data all month already, so you are not reconstructing it by hand.

A separate license per tenant is still the cleaner way to run this. It gives you cleaner limits, cleaner revocation, and cleaner usage accounting. One giant shared license might look simpler at first, but it makes tenant-level control messier later.

Usage reporting for billing

This is another area where VSPC earns its keep.

At the beginning of each month, VSPC can generate the usage report for the prior month automatically. That covers the standard billable areas you care about across a managed Veeam practice: Cloud Connect backup and replication usage, VBR rental licensing, Microsoft 365 protection, and Veeam Agent usage.

That may be enough if your billing lines up neatly with calendar months.

A lot of providers do not have that luxury. Some need mid-month snapshots. Some bill on odd cycles. Some want current per-company consumption without waiting for the automated report window. That is where the REST API becomes more useful than the canned report.

The VSPC REST API gives you real-time usage endpoints, so you can pull current consumption by company at any point in the month. For production integrations, API key authentication is the better choice. VSPC supports both API keys and OAuth password grant, but the simple API key model is easier to manage, easier to rotate, and usually easier to explain to the next person who inherits the integration.

Generate the key under Configuration > REST API Keys and save it when you create it, because that is the one time VSPC shows it to you.

From there, usage collection becomes scriptable instead of manual. That is what makes non-calendar billing cycles manageable.

Monitoring dashboards that actually matter

VSPC shows a lot. Not all of it deserves equal attention.

The most useful view for daily operations is usually the backup-jobs view filtered to Failed or Warning. That is the first place I would look every morning. It gives you a cross-tenant view of trouble without forcing you into each individual VBR console.

The next one that matters is protected workloads where the last backup is older than 24 hours. Green jobs do not always mean current protection. A tenant can still be sitting on stale recovery points even though the dashboard looks calmer than it should. That is the sort of thing you want to catch before the customer notices.

License usage near the limit deserves its own operational attention too. Set your threshold early enough that you can have the conversation before the tenant actually hits it. Waiting until the limit is reached turns a manageable account conversation into an avoidable service problem.

The same goes for Cloud Connect storage quota usage. Tenants who are about to run out of quota usually give you warning before they give you failure. That is a much better time to act.

Self-service restore for tenants

This is one of the more practical features in VSPC when you want to reduce support noise without giving tenants more power than they should have.

Through the Client Portal, tenants can handle their own item-level restores. That usually means common daily requests such as restoring a file, an email item, or another object-level recovery task that does not need provider involvement.

For Cloud Connect tenants, that item-level experience is supported directly in the Client Portal. For tenants running their own managed VBR servers, file-level restore depends on the File Level Restore plugin being deployed in the service-provider environment and on hosted VBR resources being assigned to that company in VSPC.

What VSPC does not do here is give tenants the keys to full-environment restore operations. Full VM restore remains service-provider controlled, which is the right boundary for most MSP models. Self-service is great for the everyday restore ticket. It is not where I want a customer initiating platform-level recovery actions on their own.

Final thoughts

VSPC is one of those products that sounds optional until you run a few months without using it properly.

It is free, but more important than that, it takes work that MSPs often accept as normal and turns it into something much easier to manage. Tenant onboarding becomes more structured. Licensing becomes less manual. Usage reporting becomes cleaner. Monitoring becomes centralized enough that you can actually see your customer base instead of working one VBR server at a time.

The big things to get right are not complicated. Keep the onboarding order straight. Do not bury the TLS inspection warning. Use Pulse instead of moving license files around by hand. Give each tenant their own license boundary. Use the API when your billing model is more demanding than a simple month-end report. And understand exactly where self-service restore helps versus where provider control still needs to stay in place.

That is when VSPC stops being “another Veeam component” and starts acting like the platform layer your MSP practice should have had all along.