Broadcom support portal guide: how to actually get help after the acquisition
Broadcom changed more than the VMware support logo. On May 6, 2024, VMware Customer Connect and related support tools moved into the Broadcom Support Portal. That date matters because a lot of old muscle memory now sends admins to the wrong place, or to the right place with the wrong account state.
The portal handles more than cases. Broadcom uses it for case management, product downloads, licenses, entitlements, trials, security advisories, knowledge base articles, and communities. If the account is not tied to the correct Support Site ID, the portal may look empty even when the company has an active contract.
I would not wait until an outage to test this. The failure mode is ugly: production issue, no Enterprise profile, unknown Site ID, no visible entitlements, and a support case that cannot be opened without Customer Care getting involved first. Broadcom says access processing may take up to 48 hours when approvals are required. That is a long time when vCenter is down.
What changed after the portal move
Before the migration, many VMware admins lived in Customer Connect. Licenses, downloads, cases, and account access were familiar enough that nobody thought about them until renewal season or patch day. Broadcom moved those workflows to support.broadcom.com as part of the VMware by Broadcom Day 2 transition.
Broadcom's VMware support FAQ says all VMware support portals, including VMware Customer Connect, and related services, tools, and assets were migrated to the Broadcom Support Portal on May 6, 2024. That same FAQ points users to new workflows for Site IDs, case views, password resets, MFA resets, entitlements, product downloads, case concerns, alternate case contacts, and file uploads.
The Support Site ID is the operational change that breaks the most workflows when it is missing. Broadcom describes it as the unique identifier required for support access. It may also be called Support ID, Enterprise Site ID, SID, or Site ID. After signing or renewing a contract, the customer should have a Broadcom Support Site ID tied to the contract. For some customers that is a new Enterprise Site ID; for others it is an existing Site ID that needs the correct users and entitlements mapped to it. That Site ID unlocks case management, product downloads, and My Entitlements.
That means a Broadcom login by itself is not enough. A Basic User account can exist and still be useless for VMware support. For case management, Broadcom says the user must have an Enterprise User profile linked to a Site ID with an active support maintenance contract.
Get the Site ID sorted before anything breaks
Start with this audit while the environment is healthy:
1. Log in to https://support.broadcom.com
2. Select the VMware Cloud Foundation division from the division selector
3. Open your profile menu
4. Confirm whether your account is Basic User or Enterprise User
5. Confirm the Site IDs attached to the account
6. Confirm that My Entitlements shows the expected VMware products
7. Confirm that My Cases opens without access errors
If the Site ID is missing, use Broadcom's profile build process. The Site ID workflow asks for the Site ID and phone number, then validates the Site ID against Broadcom's records. Broadcom's KB says a green check appears when the Site ID matches. It also says the account can be locked after three unsuccessful Site ID attempts, so do not guess from old PO numbers or serial numbers.
If the company already has a User Administrator for the Site ID, that administrator can approve access. If no User Administrator exists, Broadcom says the first approved request for a Site ID with no registered users is auto-granted User Administrator and Product Administrator roles. Broadcom lists the effective date for that behavior as August 29, 2024.
Do not leave this with one person. Broadcom recommends at least one administrator per Support Site ID; I would make that two named humans plus a documented break-glass process. The User Administrator role is the difference between fixing access internally and waiting for Customer Care during a maintenance window.
Why entitlements disappear
A common complaint after the migration was, "I logged in and nothing is there." William Lam's May 2024 portal notes called out the same pattern: users were still reporting entitlement issues after the Day 2 transition, and some entitlements later appeared after account work with support or account teams.
There are several different problems that look identical from the admin chair:
- The user has a Basic profile, not an Enterprise profile.
- The account is attached to the wrong Site ID.
- The company has multiple Site IDs and the product lives under a different one.
- The user is in the wrong Broadcom division selector.
- The contract is expired or not mapped to that account.
- The download is under a product SKU path the user did not expect.
Broadcom's entitlement KB says My Entitlements can be searched by serial number, Site ID, customer name, contract number, or customer number. That helps when browsing does not surface the product. Some entitlements show a download icon; other entitlement types may not because there is no software package to retrieve.
For vSphere downloads, Lam's portal notes are more practical than the generic KB wording. To download ESXi, you may need to go through the specific vSphere SKU, such as Enterprise Plus, Essentials, or another entitlement-backed SKU, then expand the version list. Drivers, tools, witness appliances, and non-primary downloads may sit under a Drivers & Tools section after the SKU is selected.
Open the case with evidence attached
Broadcom has a February 2026 KB on creating VMware support requests for VCF, vSphere, vSAN, NSX, and Aria Suite. The useful part is not the portal navigation. It is what Broadcom expects in the first submission.
Attach diagnostics when the case is created. Do not open a blank case that says "vSAN broken" and then wait for the engineer to ask for logs. Broadcom specifically calls out these collection paths:
vSphere / ESXi:
vSphere Client > host or vCenter object > Actions > Logs > Export System Logs
NSX:
NSX Manager > System > Support Bundle
For ESXi hosts, you can also generate a support bundle from the shell when the UI is not cooperating:
mkdir -p /vmfs/volumes/datastore1/support-bundles
vm-support -w /vmfs/volumes/datastore1/support-bundles
Replace datastore1 with a datastore that exists and has enough free space for the bundle.
For vCenter Server Appliance, use vc-support from an SSH session:
# If SSH opens the VCSA appliance shell first:
shell
vc-support -l
If SSH already drops into bash, skip shell. Note the generated bundle path and upload that file to the case.
If you can still reach vCenter with PowerCLI, grab a quick inventory snapshot before the outage state changes. Treat the task list as a quick view, not a replacement for vCenter events or support bundles:
Connect-VIServer -Server vcenter.company.local
Get-VMHost | Sort-Object Name | Select-Object Name,ConnectionState,PowerState,Version,Build,
@{N='Cluster';E={$_.Parent.Name}} |
Export-Csv .\vmhost-inventory.csv -NoTypeInformation
Get-Cluster | Select-Object Name,HAEnabled,DrsEnabled,VsanEnabled |
Export-Csv .\cluster-state.csv -NoTypeInformation
Get-Task | Sort-Object StartTime -Descending | Select-Object -First 50 Name,State,StartTime,FinishTime,Description |
Export-Csv .\recent-vcenter-tasks.csv -NoTypeInformation
That does not replace support bundles, but it gives the engineer a timestamped picture of the estate. It also protects you from arguing from memory two days later.
If junior admins only touch PowerCLI during incidents, keep an internal runbook with the exact commands your team uses. A book is fine for training, but it will not beat a tested local runbook during an outage.
Pick the right severity and know what it commits you to
Broadcom's severity labels are Critical P1, High P2, Medium P3, and Low P4. Their VMware support request KB defines them this way:
| Severity | Broadcom wording from KB 429027 |
|---|---|
| P1 critical | Production system down; total loss of service; requires 24x7 availability of a customer contact |
| P2 high | Production system severely degraded; core functions impacted but operational |
| P3 medium | Non-critical issue; system operational |
| P4 low | General questions or documentation clarifications |
The P1 line is the one people miss. If the case is Critical P1, Broadcom expects a customer contact available 24x7. Do not set P1 at 4:55 PM and then have the only useful admin go offline. That gives support a reason to downgrade, stall, or lose the thread.
Broadcom's severity-change KB says the severity can be changed from the case page by editing the severity field. It also says the severity will be re-categorized if it does not align with Broadcom's Software and Maintenance Policy Handbook. For P1, the portal asks for confirmation that the case meets the Severity 1 definition.
Use P1 when production is down or there is total loss of service. Use P2 when production is badly degraded but still operating. Do not inflate every annoying bug to P1. That may feel good for five minutes, then it burns credibility when the next actual outage happens.
Escalation is not the same as changing severity
Broadcom's case FAQ separates severity changes from case concerns. If the business impact changes, update severity. If the concern is that service levels are not being met, use the Raise Concern button to notify Broadcom Support Management. Broadcom explicitly says the Raise Concern path is not intended for Severity 1 escalation.
That distinction matters. A case can be correctly marked P2 and still need management attention because it has gone stale, missed a promised update, or bounced between owners. Raising concern is the cleaner move in that situation.
When raising concern, write like an incident manager, not like a forum post:
Case: 12345678
Product: VMware vSAN 8.0 U3
Current severity: P2
Business impact: 42 production VMs running degraded after disk group failure; no data loss; rebuild not progressing
Last useful update: 2026-07-15 09:20 UTC
Requested action: assign vSAN escalation engineer and confirm next update time
Customer availability: John Smith, +1-555-0100, available until 23:00 UTC
Short, dated, and specific beats three paragraphs of frustration.
Add alternate contacts before the primary admin leaves
Broadcom says alternate case contacts can be added, with up to three email addresses copied on case communications. The FAQ also says a user's email address must be added to the case contact to view the case under My Cases. To view cases opened by colleagues, use the All Cases tab, assuming the account and permissions allow it.
This is another item to test before an outage. Open a low-severity administrative case if you need to validate process. Confirm that the infrastructure lead, backup admin, and manager can see the case history. Confirm that the NOC mailbox is not the only address receiving updates. Confirm that the person who can approve a remote session is not excluded from the thread.
Build a support packet once, then reuse it
Create a folder in your internal documentation system called something boring like Broadcom support packet. Put these items in it:
- Company legal name used on the Broadcom contract
- All Broadcom Support Site IDs
- Contract numbers and renewal dates
- User Administrator names
- Product Administrator names
- VAR or Broadcom account team contacts
- vCenter FQDNs, versions, and build numbers
- ESXi version and build report
- NSX Manager version if used
- vSAN ESA or OSA layout if used
- Standard location for support bundles
- Internal bridge number for P1 and P2 incidents
Generate the version report with PowerCLI:
Connect-VIServer -Server vcenter.company.local
$report = foreach ($vmhost in Get-VMHost | Sort-Object Name) {
$view = $vmhost | Get-View
[pscustomobject]@{
Host = $vmhost.Name
Cluster = $vmhost.Parent.Name
ESXiVersion = $vmhost.Version
ESXiBuild = $vmhost.Build
Sockets = $view.Hardware.CpuInfo.NumCpuPackages
Cores = $view.Hardware.CpuInfo.NumCpuCores
Model = $view.Hardware.SystemInfo.Model
Vendor = $view.Hardware.SystemInfo.Vendor
}
}
$report | Export-Csv .\broadcom-support-host-report.csv -NoTypeInformation
Refresh that report after patching, hardware refreshes, cluster moves, and renewals. A six-month-old inventory file is still better than nothing, but a current one saves time.
What to do this week
Treat Broadcom portal readiness as an operations control, not an admin preference. The work is small compared with the cost of discovering access problems during an incident.
Verify Enterprise User access for at least two people, then test Site IDs, My Entitlements, My Cases, product downloads for the SKUs actually owned, user approvals, Raise Concern access, and P1 coverage when Broadcom asks for 24x7 customer availability.
The acquisition changed pricing, packaging, and account handling. The support portal is where those changes become operational. If the portal is ready, support still may not be fast. If the portal is not ready, support may not even start.