ActiveCluster for File Veeam Backup
Hello everyone :-) we recently got a Flasharray with the new "ActiveCluster for File" feature, which is pretty nice. We are trying to switch to Veeam. We are using VMware. I therfore created a Linux based Veeam Backup & Replication Server as well as linux based proxies in our vCenter. Backing up VMs via the hot-add transport mode works without any issues. The issue that we are facing is, how do we backup the NFS shares created from the "ActiveCluster for File"? Because Veeam sees the VMDKs from the VMs in the vCenter but doesen't see the NFS mounts from Everpure in the guest OS of the VM. My questions and thoughts are: Is it possible to create an physical Linux based on Veeam proxy and connected it to the Everpure FlashArray? According to this link, Everpure doesn't support the storage snapshot Integration feature https://helpcenter.veeam.com/docs/vbr/userguide/storage_system_requirements.html?ver=13 This is the Plugin I wanted to use with the physical proxy which is connected to the FlashArray https://www.veeam.com/kb4129 I can add the NFS Share into Veeam and create backjobs but how does it technically work? It uses the VBR Server as an proxy.. But is that the right way? How can I create Veeam backup jobs for NFS mounts (which are mounted on VMs in the vCenter, which Veeam doesn't see) provided by ActiveCluster for File ? How does a Veeam file share backup work technically and how should the recommended backup design be in this scenario? Thank you!Entra ID SAML2 SSO on FlashArray (Purity//FA 6.12.3), including fleets
Hi everyone, Here is a working setup for single sign-on from Microsoft Entra ID to a FlashArray, tested on Purity//FA 6.12.3, which is the newest version at the time of writing. It follows the Microsoft tutorial for Pure Storage SSO (https://learn.microsoft.com/en-us/entra/identity/saas-apps/pure-storage-sso-tutorial) and adds the fixes I needed to get the login test to pass. It also covers adding more arrays and fleets. Two things that break the login if you skip them The gallery app ships with role names that do not match the FlashArray role names. If you do not rename them, the login test fails because the array cannot find the role (Step 6). The claims must have no namespace URI (Step 5). What you need An array admin login Entra admin rights (Enterprise applications and App registrations) The Pure Storage SSO app from the Entra App Gallery A user or group to assign Overview Create a certificate on the array Configure SAML2 SSO on the array Entra app and the array certificate Load the Entra signing certificate on the array Claims (delete the namespace URI) Fix the app role names Assign, test and enable Plus: more arrays and fleets, and a troubleshooting list at the end. Step 1: Create a certificate on the array The array needs its own RSA certificate to sign SAML requests and decrypt assertions. Do not use the management certificate: it is EC 256 and caused a 500 error for me. purecert self-signed create saml-sp --common-name myarray.pure --days 365 purecert list The saml-sp row should show self-signed, rsa, 2048. Note the expiry date: SSO signing stops working when it expires. Step 2: Configure SAML2 SSO on the array Go to Settings › Access › Users and Policies › SAML2 SSO and edit the configuration. Array URL: the array FQDN, for example https://myarray.pure/. Signing Credential and Decryption Credential: type the certificate name saml-sp. Do not paste certificate text. Switch on Sign Request and Encrypt Assertion. IdP Entity ID, URL and IdP Metadata URL: copy them from the Entra app (Set up Pure Storage SSO section). Keep Enabled off for now and save. Without credentials, saving fails with "Must provide signing credential when signed request is enabled" and the same message for decryption. The GUI can silently keep management, so check the result in the CLI: puresso saml2 list puresso saml2 test Both credential columns must show saml-sp. If not, set them directly: puresso saml2 setattr Entra-ID --signing-credential saml-sp --decryption-credential saml-sp This can print "Certificate claim does not exist." even though the values were applied, so trust the list output. Step 3: Entra app and the array certificate In the Entra admin center go to Enterprise apps › New application, search Pure Storage SSO and add it. Open Single sign-on › SAML › Basic SAML Configuration. Set Identifier to the array's SP Entity ID and Reply URL to the array's Assertion Consumer URL. Both are shown in the array's SAML2 SSO dialog, so copy them from there. On the array, open the certificates page and download saml-sp. Rename the extension from .crt to .cer. In the Entra app go to Single sign-on › SAML Certificates › Verification certificates › Edit, tick Require verification certificates, and upload the .cer. Because Encrypt Assertion is on, also import the same .cer under Token encryption and activate it (see the token encryption guide under Links). Check that you exported the right certificate: openssl x509 -in saml-sp.cer -noout -subject -enddate The subject must show the common name you used in Step 1, not the GUI certificate. Step 4: Load the Entra signing certificate on the array The array needs Entra's signing certificate to validate the response. If this is empty the array test still shows OK, but a real login fails. In Entra open Single sign-on › SAML Certificates and download Certificate (Base64). Open the file, copy everything including the BEGIN CERTIFICATE and END CERTIFICATE lines. In the array's SAML2 SSO dialog click Edit next to Verification Certificate and paste it. CLI alternative: puresso saml2 setattr Entra-ID --verification-certificate Step 5: Claims (delete the namespace URI) In the Entra app go to Single sign-on › Attributes & Claims › Edit. Open each claim, clear the Namespace field completely, and make sure the names match exactly: dn: user.onpremisesdistinguishedname email: user.mail (or user.userprincipalname for UPN) family_name: user.surname given_name: user.givenname purity_roles: user.assignedroles (required for array level SSO) Step 6: Fix the app role names The Pure Storage SSO gallery app is set up incorrectly for its role names. It ships readonly_role, ops_admin_role, storage_admin_role and array_admin_role with an empty value. The names must match the FlashArray role names exactly, otherwise the login test fails because the array cannot find the role. The roles are edited in App registrations, not in the Enterprise application: Go to App registrations › All applications and search for the app name. Open App roles and click a role. In Display name, remove the _role suffix. In Value, enter the role name, for example array_admin. Click Apply and repeat for the other roles. array_admin_role → Display name: array_admin, Value: array_admin storage_admin_role → Display name: storage_admin, Value: storage_admin ops_admin_role → Display name: ops_admin, Value: ops_admin readonly_role → Display name: readonly, Value: readonly Leave msiam_access as it is. Step 7: Assign, test and enable In the Entra app go to Users and groups › Add user/group, pick the user, click Select a role and choose one of the renamed roles. Only one role per assignment. On the array open the SAML2 SSO dialog and click Test. All lines must be green and the first two must show saml-sp. Click E2E Test, sign in with the assigned user, then click Check E2E Test Result. If it passes, switch Enabled on and save. The login page now shows Click for Single Sign-On and a Local Access link. Tip: Keep a working local admin login in case something on the Entra side breaks or a certificate expires. More arrays and fleets Each array needs its own certificate, and that certificate must be uploaded to Entra under Verification certificates, next to the ones from the other arrays. You do not need a new Enterprise application per array. If you use Fusion / fleet manager, enable Trust Other SAML Service Providers In Fleet in the SAML2 SSO configuration and apply these settings on each additional array: Create the certificate on that array (Step 1) with its own common name. Use the same SSO configuration name as on the first array. Array URL: the FQDN of the new array. SP Entity ID: set it to Manual and paste the SP Entity ID of the first array. All fleet members must use the same SP Entity ID. Signing Credential and Decryption Credential: saml-sp, the certificate of this array. Switch on Sign Request and Encrypt Assertion. Identity Provider fields and Verification Certificate: the same values you used on the first array. In the Entra app, add a second Reply URL with the Assertion Consumer URL of the new array, and upload the new array's saml-sp .cer under Verification certificates. Run Test and E2E Test before enabling. After that you can sign in on the other arrays with the same Entra users, roles and claims. Note: If you use Encrypt Assertion on several arrays, check this: Entra token encryption uses one active certificate per application, so test each array with the E2E test. Troubleshooting Save fails: must provide signing or decryption credential: Create saml-sp and enter its name in both fields Red error echoes a long MIID... string: You pasted certificate text. Type the certificate name instead Test shows management as credential: Run puresso saml2 setattr as in Step 2 500 Internal Server Error when starting login: The credential was the EC management certificate. Switch to the RSA saml-sp certificate Login test fails, role not found: Rename role display name and value in App registrations (Step 6) Login fails or user has no role: Clear the claim namespaces and check purity_roles = user.assignedroles (Step 5) Verification certificate shows - in the test: Paste the Entra Base64 certificate (Step 4) If you do not need signed requests or encrypted assertions, you can switch off Sign Request and Encrypt Assertion and skip the certificate steps. Links Configure Pure Storage SSO for Single sign-on with Microsoft Entra ID (https://learn.microsoft.com/en-us/entra/identity/saas-apps/pure-storage-sso-tutorial) Configure Microsoft Entra SAML token encryption (https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/howto-saml-token-encryption) Manage certificates for federated single sign-on (https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on) App roles UI (https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps#app-roles-ui) Hope this saves someone some time. Questions and corrections are welcome.Purity//FB 4.8.6 FR has released
We are happy to announce the general availability of 4.8.6, the seventh Feature Release in the 4.8/4.9 line, helping customers move from managing storage to managing their data, with governance that enforces itself, a fleet that runs as one, and real-time insight that keeps critical workloads performing, all with less manual effort and less risk. See the release notes for all the details about the features and improvements included in this release.Purity//FA 6.12.3 FR has released
We are happy to announce the general availability of 6.12.3, the fourth Feature Release in the 6.12/6.13 line, including new capabilities that help customers advance their Enterprise Data Cloud with deeper VM-level workload visibility, standardized fleet-wide bucket provisioning, and simpler data replication with less complexity and risk. See the release notes for all the details about the many features, enhancements, bug fixes, and security updates included in this release.
GA: What's new in Purity//FA 6.10.5
We're excited to announce that the latest Purity//FA release is now GA! With the latest Purity//FA 6.10.5 release, customers get a tighter combination of performance, protection, and access control across their FlashArray estate. By combining ActiveCluster™ with near‑synchronous ActiveDR™, the platform now delivers a three‑site resilience capability that can help meet compliance expectations. You get zero‑RPO protection between two primary sites with ActiveCluster, replicating to a third site with ActiveDR. It’s engineered to deliver sub‑30‑second RPO and sub‑minute RTO. At the same time, support for FlashArray//ST™ R5 is here as part of the FlashArray family. It’s optimized to deliver consistent ultra low‑latency performance for OLTP, in‑memory, and real‑time workloads. Take advantage of extreme performance while maintaining consistent enterprise-grade data services. Support for NVMe/TCP with VMware 9.x and ActiveCluster means the most demanding VMware workloads don’t have to choose between performance and resilience. ActiveCluster provides zero-RPO protection, automatic failover, and active-active access for stretched datastores across NVMe/TCP. Rounding it out, Everpure Fusion now supports SAML 2.0 SSO, giving you a faster, simpler, and secure authentication experience across the Everpure Platform. Replace legacy local/LDAP logins with MFA‑backed SSO and IP‑based controls that harden your perimeter without adding operational friction while accessing FlashArray, FlashBlade, and Everpure Fusion fleets. Update to Purity//FlashArray 6.10.5 to leverage these latest innovations. Want to learn what else is new? Check out the Everpure What's New webpage today!Fusion MCP Server Is Now Released & Open Source
There’s a narrow band between “AI demo” and “actually useful in production,” and most tools miss it by a country mile. Fusion MCP Server doesn’t. Now that it’s open source, MCP-compatible AI assistants get a controlled bridge into Everpure FlashArray and FlashBlade environments, one built to answer real operational questions about fleet inventory, capacity, performance, alerts, volumes, file systems, workloads, and presets, without turning your storage estate into a science fair project. The AI Agent doesn’t get to vibe its way through your infrastructure. It works through a clean tool surface backed by real Everpure APIs, and writes stay hidden until you flip them on yourself. What it actually solves If you’ve ever wanted to ask a storage question in plain English and get something better than a dashboard scavenger hunt, this is that. Fusion MCP Server sits between your AI agent and your arrays: the assistant talks to the server, the server authenticates with configured array API tokens, calls supported Everpure APIs, and returns structured results. Your assistant never touches the arrays directly. Practically, that means engineers can ask things like: Show me the fleet overview Which arrays have capacity concerns Show array performance for the last 24 hours List workload presets available in this fleet Show active alerts with remediation links The data was never the problem. Storage teams already have it. What eats the day is bouncing between menus, tabs, and API docs just to answer something like “which arrays are closest to full?” Think of it like swapping a pile of ad hoc curl commands and tribal knowledge for a typed interface your AI assistant can reason over. Calling it “screen scraping with confidence” undersells it. It behaves more like a junior SRE who actually reads the schema. Why engineers should care The release leads with reads, which is exactly the right default for infrastructure tooling. Out of the box, Fusion MCP Server covers fleet overview, capacity and performance, storage objects, configuration audit, and optional supervised actions for placement recommendations, preset creation and updates, and workload deployment. A few details stand out: It works with FlashArray and FlashBlade environments in a Fusion fleet, including mixed environments, as long as you provide at least one token for each platform type for Remote Execution. If the API version you have on your arrays does not yet have the endpoints with Remote Execution capability enabled, you must supply an API token for every array in the fleet. More on that in the next section. Fleet discovery covers the supported read workflows broadly, though some, especially performance, still need a direct token for each array you want to query. Built-in prompts handle fleet, performance, and config workflows, and it also works through plain natural-language questions if your agent doesn’t expose MCP prompts directly. Read-only endpoint documentation plus a whitelisted authenticated GET fetch tool cover supported API surface beyond the dedicated tools. Let’s talk Tokens first Back in Purity REST API version 2.38, Everpure started to include a capability for API endpoints called Remote Execution. This is the mechanism that lets a client invoke a Purity REST API request on a different fleet member, and that request executes as though it were initiated locally on that remote member. The catch is that both arrays must have the same API version available on them as well as the endpoint being executed against must have Remote Execution capability. As of today, not all endpoints have this capability, so there must be an API token specified for each array in the fleet until they have all been enabled. We are diligently working to get all endpoints enabled to make this easier for everyone. Stay tuned! Installation (that does not require a PhD) The setup flow is refreshingly direct: Download the latest binary from GitHub Releases or build from source. Generate API tokens for the arrays you want to query. Run generate-config with your FlashArray and/or FlashBlade targets. Drop the generated config into your MCP-capable agent using the standard start --auth-config pattern over STDIO. generate-config does more than write boilerplate. It validates tokens, detects each array’s API version, resolves array names, and writes the auth config with restrictive permissions: the config directory gets 0700 and the file gets 0600. Want an even easier way? How you just tell your AI Agent to “Read this repository at https://github.com/PureStorage-OpenConnect/fusion-mcp-server and the included USER_GUIDE.md file and add the Fusion MCP server to this agent.” Easy-peasy as it’ll step you thought the process and create the config file for you. A few caveats are worth flagging before you point this at anything that matters: The published binaries aren’t signed, so macOS and Windows may throw a warning on first run. Build from source if that’s a dealbreaker. It’s all there, have at it! Keep the generated auth-config.json local, don’t share it, and rotate tokens if one ever leaks. None of that is friction. It’s the fine print you’d want before trusting a tool with API tokens. Supervised write actions: powerful, optional, and very much not on by default Now for the part everyone asks about first, and the part some people should absolutely not enable first: write actions. Fusion MCP Server hides write tools by default. You turn them on explicitly, either during config generation with --enable-write-tools or later with update-config --enable-write-tools. Enabled, the supervised actions cover these processes with more to come as the product evolves: Placement recommendations Workload preset creation Workload preset updates Workload deployment The approval step is the clever bit. Write operations sit behind an explicit confirmation. If the agent supports MCP Elicitation, the server pops up an interactive dialog for every write tool, so you can review the proposed action and approve or decline before anything changes. If the agent doesn’t support Elicitation, it falls back to telling the agent, in plain instructions, to ask you for approval before resubmitting the call. One practical wrinkle: the write tools inherit whatever permissions live on the API tokens you configure, so the workflow only works if those tokens can perform the write. So when should you flip the switch? Enable write tools if you want supervised acceleration on repeatable workflows: placing a workload from a known preset, updating a policy-backed preset, or turning a natural-language request into a deployment action that still needs a human to sign off. Skip it if you’re still validating token scope, using the server mainly for observability, or introducing MCP to a team that hasn’t built trust in the read-only workflows yet. Start with read-only. Make it boring. Then decide whether supervised writes are the next move. Write tools toggle on and off with a simple update-config command, so this isn’t a one-way door: turn them off again anytime with update-config --enable-write-tools=false. Use cases that actually matter This release isn’t for people who like screenshots of AI chats. It’s for engineers and operators who want faster answers and safer workflows. A few obvious wins: Fleet triage Ask for a fleet overview with alerts, array inventory, Purity version, and fleet connections, the kind of first-response context you want before guessing which dashboard to open. Capacity and performance review Ask which configured arrays have the highest used capacity, which have high latency, or pull performance for the last 24 hours. For teams juggling multiple arrays, this turns routine health checks into a single conversation. Storage object lookup Query volumes by naming pattern, list file systems on FlashBlade, or inspect workloads on a specific array. Useful for anyone who inherited naming conventions from a previous geological era. Configuration audit Use the built-in documentation and read-only fetch coverage to compare settings across arrays and check for policy consistency. Handy if you’re trying to catch drift without hand-rolling an audit script every quarter. Workload lifecycle acceleration Enable supervised writes and the assistant can recommend placement, create or update presets, and deploy workloads from those presets. At that point the server stops acting like a reporting tool and starts acting like an interface layer for intent-driven operations. On My Soapbox: Why the Open Source release matters Being open source here changes the trust model, not just the distribution channel. You can inspect how the bridge works, check the security assumptions yourself, and contribute fixes instead of filing a ticket into the void. When reality disagrees with the documentation, which happens to every project sooner or later, you can open an issue instead of just living with it. The repository is public under Apache 2.0, with contribution guidance, architecture notes, a developer guide, and a dedicated issue tracker for support, issues, and feature requests. That means the people who’ll stress-test this in real environments can also be the ones fixing it. For a tool sitting between AI agents and production-adjacent storage workflows, that’s where the engineering conversation belongs. Final thought Fusion MCP Server is short on hype and long on mechanical sympathy. Read workflows stay front and center, write workflows require your explicit sign-off, and installation doesn’t eat your afternoon. If you’re running Fusion-managed fleets (which y’all should be!), it’s worth a look. Grab the latest release, point it at your MCP-capable agent, start read-only, and see how fast “show me my fleet overview” becomes second nature. It’s open source. Once you’ve kicked the tires, contribute code if you build something useful, and open an issue when you hit an edge case. That’s the whole deal.
