CommPulse

so this happened our old phone system was a mess. on-prem PBX from like 2015. constantly dropping calls, hard to scale, and every time something broke I had to drive to the office to fix it. I hate driving to the office. I pitched moving everything to Azure. compute, storage, the whole thing. took me like 3 weeks to build the business case. showed him cost projections, uptime improvements, scalability. he finally said yes. we went with phone system for the actual calling layer and built the rest on Azure. recordings go to blob storage, analytics run on functions, the whole stack. honestly it's been solid. we had one hiccup with network security groups blocking SIP traffic but that was my fault for not configuring it properly. now whenever someone asks about the phone system I'm like it's on Azure and they nod like I'm some kind of genius. I'm not. I just read a lot of documentation. the best part is I haven't had to drive to the office in 4 months. that alone is worth the migration. anyone else running voice workloads on Azure. any tips for cost optimization because I'm terrified of the next bill submitted by /u/Ramsesthrowaway to r/AZURE [link] [comments]

Disclosure: I maintain this (free, open source, self-hosted). If your Kubernetes pods request a lot more CPU/memory than they use, you are paying for idle capacity. Attune watches real usage and right-sizes those requests, often without restarting pods (in-place resize on modern Kubernetes). Repo: https://github.com/attune-io/attune Docs: https://attune-io.github.io/attune/ Requirement: usage metrics in the cluster (Prometheus is the usual case; Datadog/CloudWatch also work). Without metrics there is nothing to right-size from. If underuse is real for you, what is the barrier to starting and saving money? Do not trust automation on prod Already use something else No metrics / install friction Hard to prove savings in $ Change management / security What would block you most? submitted by /u/Mobidic69 to r/FinOps [link] [comments]

Maybe we need to change the way we handle access process for our developers or users. There was a production outage but luckily it wasn't revenue impacting. I had to help a developer by accessing their application on an ec2 instance. Our team have access to any servers in production. Our developers only have access to our dev and stage environments. I am not familiar with their application. So basically, I was just executing commands that he was giving me. It was the most degrading role I have experienced, HAHAHA! I'm thinking that when there are production outages, the application owners should be given temporary access so they can debug their applications. It will be quicker. It took us almost 5 hours! I was just copying and pasting commands and outputs. On the unix history command recalls everything. I don't recall any, HAHAHA! So what is your process? submitted by /u/Oxffff0000 to r/devops [link] [comments]

Most teams I talked to don't have a CI/CD pipeline checking cost or governance policy before terraform apply, they just run it locally. That's what guard is for: cloudcosttree guard -- terraform apply. To be clear, this isn't a simulation, it's your real terraform apply. guard never runs one on its own, it only wraps the exact command you were already going to run, checks the plan against your policies, then applies that same saved plan, so there's no gap between what got checked and what got deployed. Default behavior is warn-only, it prints violations but still applies. --block opts into actually stopping the apply on a real violation. A false positive blocking a real deploy is worse than one showing up in a report, so blocking is never the default. submitted by /u/Independent-Ease-609 to r/FinOps [link] [comments]

I'm still seeing the old GPT pricing in Foundry Monitoring and in my Azure cost management for Standard Global as of today, does anyone know when they will fix this? It's been 12 days now... Support isn't helpful and doesn't have any clue it seems. submitted by /u/googleaddreddit to r/AZURE [link] [comments]

Context: I'm running a public API on API Gateway + Lambda, with DynamoDB behind it. Endpoints have very different backend costs, cheap reads vs. a couple of routes that kick off heavier aggregation work. Currently using API Gateway usage plans with a single throttle limit per API key, applied flat across all routes. The problem: usage plans throttle by requests/second regardless of which route is hit, so a client hammering cheap GETs eats the same budget as one calling the expensive routes, and there's no way (as far as I can find) to weight individual routes differently within a single usage plan without splitting them into separate API Gateway stages/plans per cost tier, which gets awkward to manage as the number of "cost classes" grows. What I've looked at so far: Per-stage/per-plan splitting: works, but means maintaining N usage plans and N sets of API keys per client if a client needs access to routes at more than one cost tier. Custom Lambda authorizer + DynamoDB counter: doing weighted token-bucket logic myself (consume different token amounts per route, check/decrement atomically via DynamoDB conditional writes), seems doable but adds a DynamoDB read/write on every request just for the rate-limit check, plus I'd be reimplementing throttling that API Gateway mostly already does for free. Briefly looked at whether Lambda reserved/provisioned concurrency per function could act as an implicit cost-based limiter (route the expensive endpoint through its own function with tighter concurrency), but that limits total throughput, not per-client fairness. Has anyone actually shipped weighted/cost-based rate limiting on top of API Gateway usage plans, or does everyone end up rolling their own with a Lambda authorizer + DynamoDB/ElastiCache counter once costs diverge enough between routes? And if you rolled your own, did you keep API Gateway's built-in throttling as a coarse backstop on top of it, or drop it entirely in favor of the custom logic? submitted by /u/ClickOk5811 to r/aws [link] [comments]

I need some help figuring out if this is a highly targeted scam or a legitimate invoice. I recently received an email containing a PDF invoice for an "Unreturned Advance Exchange Fee". The sender email is ⁠ [email protected] ⁠. Here is what is really tripping me up and making me second-guess: The details of the item on the invoice (a Surface Laptop) and the serial number of the returned item is correct. My personal and organization details listed in the "Bill To" and "Ship To" sections are 100% correct. The invoice claims to be from "MICROSOFT PTY LIMITED" based in North Sydney, Australia, and the total amount is listed in AUD. **The Red Flag:** The "Remit to Bank" section instructs me to send payment to "BANK OF AMERICA". I am based in the Asia Pacific region, so seeing Bank of America as the payment destination feels incredibly suspicious, even though Microsoft is a US-based company. Has anyone else dealt with this before? Is it normal for Microsoft's APAC/Australian branches to use Bank of America for direct wire transfers, or is this just a very sophisticated, highly personalized spoofing attempt using an email address like **⁠ [email protected] **⁠? Customer Success Manager from MS hasn’t replied in a week where I asked if this is legit and I should reply to it. Also btw device was returned within directed time frame. Any advice would be greatly appreciated! submitted by /u/laleric to r/sysadmin [link] [comments]

terraform plan validates syntax and state, it has no opinion on whether the instance size you picked is actually right for the workload. Ran a single-resource RDS example through CloudCostTree: db.t3.large, declared as-is, comes out to $107.28/month, Cost Score F. Simulating one size down, db.t3.medium, same file, no architecture change: $57.64/month. A real $49.64/mo drop, 46.3%. Nothing about that shows up in a terraform plan diff, you only see it once you actually price the resource. submitted by /u/Independent-Ease-609 to r/FinOps [link] [comments]

I wanted to test one specific path: Amazon Bedrock AgentCore (AWS) | +-- MCP --> live exchange-rate tool | +-- A2A v1.0 --> Microsoft Foundry hosted agent (Azure) On July 29, 2026, that path worked end to end. An AgentCore-hosted Strands coordinator called a Microsoft Foundry agent over A2A v1.0, authenticated with Microsoft Entra, and compared the reply with an independent MCP conversion. For the smoke case, both sides converted 100 USD to EUR using a rate of 0.87873 and returned 87.87300 . The deterministic comparator reported zero relative difference and no warnings. This article shows how to run that demo and documents what failed on the way. The code is in xbill9/bedrock-foundry-a2a-currency . What the demo measures This is not intended to be a currency chatbot. Currency conversion gives the demo a small domain with exact arithmetic, a public data source, and answers that are easy to compare. The coordinator supports three modes: Mode Path mcp_only AgentCore calls the exchange-rate MCP tool a2a_only AgentCore delegates to the Foundry agent over A2A verified Both calls run concurrently and deterministic code compares the results The LLM selects and explains the workflow. It does not calculate the conversion or decide whether two amounts agree. Python Decimal does that: difference = abs ( primary . converted_amount - verifier . converted_amount ) relative_difference = difference / abs ( primary . converted_amount ) agreed = relative_difference <= Decimal ( " 0.005 " ) If the two sources disagree, the coordinator returns both quotes. It never asks a model which number looks better. Architecture CLI / test runner | | SigV4 v Amazon Bedrock AgentCore Runtime, us-east-1 Strands Agents coordinator, Amazon Nova Micro | +-- MCP stdio | | | +-- Frankfurter daily reference rates | +-- AWS Secrets Manager | | | +-- Entra service-principal credential | +-- Entra OAuth client-credentials exchange | +-- A2A v1.0 JSON-RPC | v Microsoft Foundry hosted agent, East US 2 Microsoft Agent Framework, gpt-5-mini | +-- MCP stdio | +-- Frankfurter daily reference rates The two agents use the same rate provider deliberately. This smoke test is about transport, authentication, tool use, and cross-framework agreement, not about reconciling different market feeds. Prerequisites You need: Python 3.11 or later Node.js 20 or later AWS CLI v2, authenticated to the target account Azure CLI 2.80 or later Azure Developer CLI ( azd ) with the Foundry agent extension permission to deploy AgentCore resources in AWS permission to create a Foundry project and hosted agent in Azure Install the AgentCore CLI and authenticate: npm install -g @aws/agentcore aws sts get-caller-identity az login azd auth login The Azure identity performing the deployment needs Foundry Project Manager on the Foundry project. Azure management-plane Owner or Contributor alone does not grant the data-plane agents/write action. Run the credential-free local checks Clone the repository and install into the current user's Python environment. The related benchmark repositories expose the same console-script names, so invoking modules from the intended checkout avoids accidentally running a sibling clone. git clone https://github.com/xbill9/bedrock-foundry-a2a-currency.git cd bedrock-foundry-a2a-currency pip3 install --user --break-system-packages -e ".[dev]" pip3 install --user --break-system-packages -r requirements.txt PYTHONPATH = . python3 -m pytest -q The July 29 build passed 66 tests. These cover the Decimal domain logic, MCP subprocess transport, failure policies, Entra credential parsing, and a Foundry-shaped authenticated A2A v1.0 server. Try the three modes with deterministic fixture rates: PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode mcp_only PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode a2a_only PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR --mode verified --transport mcp-stdio --json Fixture results prove orchestration and protocol behavior. They are not financial quotes. Deploy the Microsoft Foundry peer The repository's deployment script packages the Foundry agent, provisions the project and gpt-5-mini model deployment, deploys the hosted agent, enables incoming A2A, and reads back the authenticated v1.0 agent card: ./infra/deploy_foundry_peer.sh The script prints an endpoint shaped like: https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a Save it for the next steps: export CURRENCY_FOUNDRY_A2A_ENDPOINT = "https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a" The card is not public. Foundry serves it at agentCard/v1.0 , and it requires an Entra bearer token just like the message endpoint. Before involving AWS, test the real Foundry peer from the local coordinator. The local path uses your ambient Azure CLI credential: CURRENCY_RATE_PROVIDER = frankfurter \ CURRENCY_FOUNDRY_A2A_ENDPOINT = " $CURRENCY_FOUNDRY_A2A_ENDPOINT " \ PYTHONPATH = . python3 -m coordinator.cli \ 100 USD EUR \ --mode verified \ --transport mcp-stdio \ --a2a-peer foundry \ --timeout-seconds 90 \ --json Expect mcp-stdio:frankfurter-live as the primary source and hosted-foundry-a2a as the verifier. Give the AWS runtime an Azure identity An AgentCore runtime has an AWS IAM role, but it has no Azure identity. Foundry does not accept an API key for incoming A2A. The demo uses a dedicated Entra service principal with Foundry Agent Consumer on only the Foundry project. Create that identity using your organization's normal process, grant the project role, and place the client secret in a protected local file. Then run: export AZURE_TENANT_ID = "<tenant-id>" export AZURE_CLIENT_ID = "<application-client-id>" export AZURE_CLIENT_SECRET_FILE = "/secure/path/to/client-secret" export CURRENCY_AZURE_SECRET_ID = "bedrock-foundry-a2a/azure-service-principal" ./infra/configure_azure_secret.sh That script stores a JSON credential in AWS Secrets Manager without putting the secret on the command line. It also prints the narrow IAM policy needed by the generated AgentCore execution role: { "Effect" : "Allow" , "Action" : "secretsmanager:GetSecretValue" , "Resource" : "<the-one-secret-arn>" } Do not place the client secret in agentcore.json . Runtime environment variables are visible through the control plane. Deploy the AgentCore coordinator Configure the AWS target and deploy once: ./infra/configure_aws_target.sh ./infra/sync_app.sh agentcore deploy -y agentcore status Grant the generated execution role the one-secret policy printed by configure_azure_secret.sh . Now point the runtime at Foundry and redeploy: export CURRENCY_AZURE_SECRET_ID = "bedrock-foundry-a2a/azure-service-principal" export CURRENCY_FOUNDRY_A2A_ENDPOINT = "https://<account>.services.ai.azure.com/api/projects/<project>/agents/currency-a2a-agent/endpoint/protocols/a2a" ./infra/point_coordinator_at_foundry.sh The script updates the local, account-specific runtime configuration, syncs the bundle, deploys it, checks status, and runs a smoke request. Keep the generated endpoint and account configuration out of Git. Run each hosted mode explicitly: agentcore invoke "Convert 100 USD to EUR in mcp_only mode." agentcore invoke "Convert 100 USD to EUR in a2a_only mode." agentcore invoke "Convert 100 USD to EUR in verified mode." Observed results These are the hosted smoke observations from July 29, 2026. They are not a latency distribution and should not be read as a platform benchmark. Mode Observed source Result Observed tool latency mcp_only mcp-stdio:frankfurter-live rate 0.87873 , amount 87.87300 about 4.2 s a2a_only hosted-foundry-a2a rate 0.87873 , amount 87.87300 about 18.8 s verified both sources zero relative difference, no warnings MCP about 3.1 s; A2A about 18.1 s The verified path runs both legs concurrently, so its tool time is dominated by the slower Foundry call rather than the sum of both calls. The important result is functional: AWS SigV4 invocation, Bedrock tool use, MCP stdio, AWS Secrets Manager, an Entra client-credentials exchange, Foundry agent-card discovery, and A2A v1.0 JSON-RPC all completed in one request. The full 38-case AWS-to-Foundry matrix, repeated warm/cold distributions, token use, and cloud cost have not been measured yet. Failures found while building it Foundry deployment returned 403 The Azure resource deployment succeeded, but hosted-agent creation failed with: Identity does not have permissions for Microsoft.CognitiveServices/accounts/AIServices/agents/write Assigning Foundry Project Manager at the project scope fixed it. Azure Owner did not imply this Foundry data-plane permission. The Foundry container never became ready The manifest passed an unset AZURE_AI_MODEL_DEPLOYMENT_NAME template value. The container exited with: ValueError: Model is required The model deployment is owned by the same manifest, so the fix was to set its known deployment name, gpt-5-mini , explicitly. The AgentCore A2A leg lacked aiohttp azure.identity.aio uses Azure Core's optional aiohttp transport. The first hosted invocation failed before token acquisition because aiohttp was not declared in the CodeZip application's own dependency manifest. Adding and locking aiohttp==3.13.3 in app/CurrencyCoordinator/pyproject.toml fixed the deployed runtime. Adding it only to the repository-root requirements file was not enough; CodeZip resolves the application bundle independently. Each of these interoperability failures now has a regression test or a manifest assertion. What A2A added For this small conversion, MCP alone was faster and sufficient. A2A added an independently hosted implementation, a separate model and framework, another tool invocation, and a distinct failure boundary. It also added real engineering work: cross-cloud identity and least-privilege role assignment authenticated agent-card discovery protocol-version pinning another cold-start boundary more dependency and deployment surfaces That overhead is worthwhile only if independent execution, failover, or cross-framework portability matters to the application. The demo now gives us a reproducible way to measure that tradeoff instead of treating an HTTP 200 as proof of interoperability.

The first time a Kyverno CLI test lied to me, I did not know it was lying. My suite went green. My PR merged. And the rule that was supposed to block a suspiciously permissive Deployment simply had not run against it in a cluster, because the policy referenced a GlobalContextEntry lookup and the CLI had no live Kubernetes API to resolve it against. So the engine did what the engine had always done in that spot: it skipped, and kyverno apply did not tell me. A CNCF blog post from July 22 walks through how a Kyverno contributor finally taught the CLI to fake production convincingly enough that offline tests for policies with those lookups stop lying. The gap the CLI had been papering over The post frames the underlying problem as an architectural mismatch. Kyverno's policy engine wants to talk to a live informer cache: unstructured resources wrapped in []interface{} slices, in exactly the shape a running controller receives them. In kyverno apply mode there was no informer cache, and any policy that reached for one, most commonly through GlobalContextEntry , would either panic outright or silently skip the rule. The tests kept passing. The rule kept not running. If you have ever added a lookup to a validating policy and then wondered why your local test never exercised it, this is the shape of the bug you were living with. The disguise, not a rewrite The author's move here is that the fix does not belong in the engine. The engine already knows how to talk to a live cache. What was missing was a translation layer between test data on disk and the shape the engine expects in memory. So they wrote one. Mock resources are decoded through runtime.RawExtension inside a new resolveResourcesMockData function, packed into the same []interface{} slices a real informer would return, and fronted by an in-memory fake dynamic client that stands in for the API server during kyverno apply . Nothing in the engine changes. It thinks it is talking to a cluster. I like this shape a lot. When a test tool starts hacking the code under test to be more testable, the tests get faster and the production behaviour starts to drift. This goes the other way. What lands in your test manifests The post lists the new fields your Kyverno test YAML can now carry: apiCallResponses , for canned responses to arbitrary API calls a policy makes. globalContextEntries , for the exact class of lookup that used to force a skip. resources and resourceFiles , for the mock inventory the engine reads through the fake client. jsonPayloads , an array of payloads for tests that need to fan out over multiple inputs. generatedResources , for verifying the multiple objects a generate policy actually produces. Two new CLI flags widen the surface further: --http-payload and --envoy-payload let you drive tests with the payload shapes Kyverno already handles at runtime. And CleanupPolicy and ClusterCleanupPolicy are now testable in dry-run mode, which closes a lifecycle gap the CLI had been carrying for a while. Why this matters at PR time This is about tests that mean something. A CI stage that runs your Kyverno policies against representative resources and either fails your PR or does not, without needing a live cluster or a kind sidecar, is the difference between finding out from your editor and finding out from the platform team next Wednesday. Every offline gate that quietly stopped running was a foot-gun. Closing that class of foot-gun is worth more than any raw-speed improvement I can remember shipping in this space. The honest rough edges A mock is still a mock. What the CLI now models faithfully is what the engine sees, not what a busy cluster actually does. Admission chain ordering, races between generate policies and their targets, and quota interactions that only bite under real controller latency are not in scope for this. You still want a smoke test in a real (probably ephemeral) cluster before you flip a policy to enforce. The other rough edge is that your test manifests get busier. Any fixture that used to pass by not exercising a lookup now has to declare the context that lookup would have found. That is more code to maintain, in exchange for tests that tell the truth. What I am watching next Whether the "fake the informer cache, do not touch the engine" pattern spreads. OPA/Gatekeeper has its own unit-test story built around conftest and Rego fixtures, and the trade-offs it makes for offline testing are different. If admission-control tooling across the ecosystem converges on standing up an in-memory API shape rather than skipping past the interesting rules, the meaning of "unit-testable policy" quietly changes underneath us. I would take that quiet change over another benchmark chart any day.

Hi everyone, so we're looking to better manage our AI spend across multiple dev teams mainly on how to deal with the fluctuating and unpredictable cost of it all. We've already set team / project specific API keys so we can track spend by project, so now I'm just looking for ways to manage the cost itself as a whole. I looked into LLM routers / gateways, mainly from seeing the Ramp Router announcement and it looked interesting to me from a cost cutting perspective. But I have 0 experience in using LLM routers so would love to hear from you guys. I'm open to other suggestions too of course, thanks! submitted by /u/Dangerous_End8856 [link] [comments]

I only have two VM's. I can see in Billing -> Reports I am getting charged $2/day for Persistent Disk. But I can't tell which VM is accounting for most of that charge. submitted by /u/imitation_squash_pro to r/googlecloud [link] [comments]

I know this is obsessive. That is the point. For time, my definition of a clean Windows installation was simple: Create an official Microsoft installation USB. Boot from it. Delete every partition. Install Windows. Sign in with a Microsoft account. Install Windows and Microsoft Store updates. Remove the applications I did not need. Install the drivers from my laptop manufacturer. Apply all my personal settings. Windows was clean, updated, and ready. Or at least, that was what I thought. The standard clean installation was not clean enough The first problem was driver installation. As soon as Windows connected to the internet, Windows Update started installing drivers automatically. After that, I installed the official driver packages from my laptop manufacturer’s website. This meant Windows could install one driver first, and then the manufacturer’s installer could install another version over it. Sometimes everything worked, but the process did not feel controlled. Windows Update also tried to install many updates, drivers, and Microsoft Store components simultaneously. This occasionally produced failed updates, retries, and unnecessary confusion. There was another issue: removing applications after they had already been installed did not feel truly clean. The applications had already been registered, initialized, and possibly updated. Uninstalling them afterward was not the same as preventing them from being installed in the first place. Improvement 1: Complete the first boot without internet My next method was: Install Windows → Complete OOBE using a local account → Enter the desktop without internet → Install the official laptop drivers from USB → Restart → Connect to Wi-Fi → Install Windows and Store updates → Remove unwanted applications → Apply my settings This was much better. Windows Update could not install random drivers before I installed the correct manufacturer drivers. It felt almost perfect. But it still was not perfect. When I finally connected to the internet, Windows still had to process a large cumulative update, smaller updates, driver checks, security updates, and Store updates at the same time. There were still occasional update errors and retries. Improvement 2: Install the large cumulative update offline I decided to integrate the latest large cumulative update into Windows before connecting the computer to the internet. The idea was simple: Install the large update offline → Boot Windows → Connect to the internet later → Download only the smaller remaining updates This significantly reduced the work Windows Update had to perform after the first boot. Instead of downloading and processing a massive cumulative update alongside everything else, Windows only needed the smaller updates released afterward. The process became faster, more predictable, and less likely to produce errors. But I still had two problems: Unwanted applications were being installed before I removed them. Manufacturer driver packages contained drivers for hardware my laptop did not actually have. Improvement 3: Extract and select the exact drivers Many laptop manufacturers provide one driver package that supports several possible hardware configurations. For example, a Wi-Fi driver package may include: Intel drivers Realtek drivers Qualcomm drivers MediaTek drivers My laptop only uses one of them, but the complete package may copy or stage drivers for several supported configurations. That did not feel precise enough. I started extracting the manufacturer’s .exe driver packages and examining the files inside them. I identified the exact hardware installed in my machine and selected only the appropriate drivers. However, I also learned that not every driver should be treated the same way. Some drivers are primarily standard INF-based packages and work well with offline DISM injection. Other packages are more complex and may include: Multiple dependent drivers Services Registry configuration Software components Firmware utilities Control panels Microsoft Store or UWP companion applications Custom installation logic Graphics, audio, and some Intel platform or firmware packages can fall into this category. For those packages, blindly extracting every INF file and injecting everything is not necessarily correct. I therefore inspected each driver package and divided them into two groups: Safe standard drivers → Inject offline with DISM Complex software-assisted drivers → Install after the first desktop boot using the official installer This gave me control without breaking the functionality supplied by the manufacturer. Improvement 4: Inject drivers before Windows boots Even when the correct driver was installed, installing it after reaching the desktop could temporarily restart or reinitialize the related device. For example, installing a network driver can cause the adapter to disappear and reappear. That is completely normal, but I wanted the hardware to be ready from the first real Windows boot. I therefore started servicing install.wim offline with DISM. My early method was: Copy install.wim from the official Microsoft ISO → Mount the WIM → Inject the safe drivers → Inject the cumulative update → Modify the image → Commit and unmount it → Use the modified image for installation DISM is already part of Windows, so the entire servicing stage could be performed using Microsoft’s own deployment tools. At this point, the installation already had the correct core drivers and the largest Windows update before it ever reached the desktop. Improvement 5: Prevent unwanted Store applications from being provisioned Microsoft Store applications are commonly provisioned in the Windows image. Provisioned applications are prepared so that Windows can register them when a new user account is created. Instead of allowing these applications to register and then uninstalling them afterward, I removed the unwanted provisioned packages from the offline image using DISM. First, I listed the provisioned packages: dism /Image:W:\ /Get-ProvisionedAppxPackages Then, for each package I did not want: dism /Image:W:\ /Remove-ProvisionedAppxPackage /PackageName:<exact-package-name> This meant the applications were removed before my user profile was created. I did not remove essential components such as Microsoft Store or Desktop App Installer. I only removed applications I had already decided I would never use. This felt much cleaner than uninstalling them after the first login. Improvement 6: Prevent OneDrive Setup from starting for the new user OneDrive was a separate case. It was not simply a provisioned Store application in the same way as the other packages. Windows contained a startup entry that launched OneDrive Setup when the user profile was created. I loaded the offline default-user registry hive and removed the OneDrive Setup startup entry. That stopped OneDrive Setup from automatically running when the first user account was created. Again, the objective was not to install something, allow it to initialize, and then remove it. The objective was to prevent the unwanted setup process from starting at all. Improvement 7: Apply my settings before the first login I then realized that many settings could also be applied offline. Instead of entering the desktop and manually changing everything, I loaded the offline registry hives and configured settings such as: Dark application mode Dark Windows interface mode Windows Spotlight policies News and Interests Delivery Optimization Fast Startup OneDrive startup behavior Other system and default-user preferences The settings were therefore present when Windows created the user profile. The system started in the state I wanted instead of starting with default settings and being changed afterward. Everything was now: Official Controlled Repeatable Performed with built-in Windows deployment tools Completed before Windows created its first normal user session But I still was not satisfied. The normal USB installer still hid too much of the process Even with a customized install.wim, the normal Windows Setup interface was still performing many operations automatically. It created partitions, applied the image, configured the boot files, and prepared recovery behind the scenes. That is convenient for normal users. For my perfection-obsessed installation, however, I wanted to know and control exactly what was happening. So I stopped using the normal graphical installation process. I moved the entire deployment into WinRE. The final method: Build Windows manually from WinRE WinRE is a small recovery environment that boots into RAM and provides access to tools such as DiskPart, DISM, BCDBoot, Registry Editor, and ReAgentC. I placed the official Microsoft install.wim, updates, drivers, answer file, and recovery image on a separate drive. Then I booted into WinRE and manually built the complete Windows disk. Step 1: Create the GPT partition structure manually I selected the correct target disk, deleted the existing partition structure, and manually created: EFI System Partition — 300 MB FAT32 Microsoft Reserved Partition — 16 MB Windows partition Windows Recovery partition — 2048 MB This gave me full control over the partition sizes, order, and purpose. The EFI, Windows, and Recovery partitions were assigned temporary drive letters during deployment. Step 2: Apply the official Windows image Instead of running Windows Setup, I applied the Microsoft image directly: dism /Apply-Image /ImageFile:C:\install.wim /Index:1 /ApplyDir:W:\ At this stage, W: contained a fresh Windows installation that had never booted. Step 3: Service the offline installation While Windows was still completely offline, I: Injected the compatible drivers Installed the latest large cumulative update Removed unwanted provisioned applications Modified the default-user and system registry hives Disabled the OneDrive Setup startup entry Applied my preferred Windows settings Added the unattended configuration Cleaned the component store For the final component cleanup, I used: dism /Image:W:\ /Cleanup-Image /StartComponentCleanup /ResetBase I only used /ResetBase after finalizing the update state because it prevents the integrated updates from being uninstalled later. Step 4: Configure OOBE officially through Panther A recent Windows 10 update complicated the local-account path during OOBE, and Windows 11 also strongly encourages online account creation. There are command-line workarounds that restart or interrupt OOBE, but that did not feel clean to me. Instead, I used a Windows answer file in the Panther directory: W:\Windows\Panther\unattend.xml The answer file configured items such as: Language Keyboard layouts Time zone Local user account OOBE behavior Automatic initial login This is part of Windows Setup’s own unattended-deployment system. It did not require third-party bypass tools or interrupting OOBE with an improvised restart. Any plaintext password contained in the answer file should be removed after Setup is complete. Windows 11 builds can behave differently, so an answer file should be validated against the specific build being deployed. Step 5: Create the UEFI boot files manually I generated the boot environment directly from the applied Windows installation: W:\Windows\System32\bcdboot.exe W:\Windows /s S: /f UEFI This created the UEFI boot files on the EFI System Partition. Step 6: Build and register the recovery environment I created the recovery directory, copied winre.wim, and registered it against the offline Windows installation: md R:\Recovery\WindowsRE copy /y C:\winre.wim R:\Recovery\WindowsRE\winre.wim W:\Windows\System32\reagentc.exe /setreimage /path R:\Recovery\WindowsRE /target W:\Windows I then assigned the proper recovery-partition GPT type and attributes and removed its temporary drive letter. The result was a complete disk containing: A fresh UEFI boot partition Windows A properly configured recovery environment No previous user activity No Audit Mode session No Sysprep generalization cycle The controlled first boot The offline deployment was only the first stage. For the first real boot, I still kept the laptop disconnected from the network. My sequence was: Boot Windows without internet → Complete the local OOBE process → Enter the desktop → Install the complex official driver packages → Restart → Pause Windows Update temporarily → Connect to Wi-Fi → Allow required OEM and Store components to install → Run Windows Update → Update Microsoft Store applications → Apply the remaining personal settings → Install required DirectX and Visual C++ runtimes → Restart again The complex driver packages included components that were better installed through their official installers, such as graphics, audio, and certain Intel platform packages. After connecting to the internet, official companion applications such as Dolby or Intel software could install normally. Because the large cumulative update had already been integrated offline, Windows Update only had a relatively small amount of remaining work. Because unnecessary provisioned applications had already been removed, Microsoft Store also had fewer applications to register and update. At this point, I had a complete Windows installation with: Official Microsoft Windows files Official manufacturer drivers Official NVIDIA drivers Official Microsoft updates Official Microsoft Store components My complete configuration No random third-party customization utility No unnecessary driver families No unwanted provisioned applications A working EFI partition A working WinRE partition This was finally the Windows state I wanted. But there was one final problem. Reproducing all of this again would take hours. Preserving the perfect state Once I started using Windows normally, installing random applications, testing software, and modifying files, the installation would no longer be in that carefully prepared state. I wanted to preserve it before normal use. Windows includes the older system-image backup concept, and many third-party disk-cloning tools also exist. However, I had completed the entire deployment using Windows-native tools. I did not want the final backup stage to depend on an unrelated third-party cloning application. So I returned to WinRE and used DISM again. WIM capture First, I captured the Windows partition into a WIM file: dism /Capture-Image /ImageFile:C:\Final-Windows.wim /CaptureDir:W:\ /Name:"Final Ready-to-Use Windows" /Compress:max /CheckIntegrity /Verify Because the capture was performed from WinRE, the Windows installation was offline. The WIM represented the files on the Windows partition at the exact point when I shut the system down. Restoring it later would return the Windows partition to that state. However, a WIM only captures the selected partition. It does not automatically preserve: The EFI partition The Microsoft Reserved partition The recovery partition The complete disk layout To restore a WIM to a completely empty disk, I would still need to recreate the partitions, apply the WIM, rebuild the boot files, and configure recovery again. That was not perfect enough for my objective. FFU: The complete-disk image DISM also supports Full Flash Update images. Instead of capturing only the Windows partition, an FFU captures the physical disk layout. From WinRE, I used: dism /Capture-FFU /ImageFile:C:\Final-Windows.ffu /CaptureDrive:\\.\PhysicalDrive1 /Name:"Final Perfect Windows" The FFU contains the complete disk: EFI partition MSR partition Windows partition Recovery partition Partition order Boot files Windows files Drivers Updates Applications Settings Recovery configuration Now I can boot into WinRE, erase the target disk, and apply the FFU. It recreates the complete disk structure and restores the files to the captured state. Instead of repeating hours of partitioning, servicing, driver selection, updating, and configuration, I can restore the complete prepared Windows environment in a small fraction of the time. It is effectively like returning the machine to the exact day when I finished preparing it. The WIM remains useful as a flexible Windows-partition backup. The FFU is the complete bare-metal recovery image. The final result My complete workflow became: Official Microsoft ISO → Manual GPT partitioning in WinRE → Direct DISM image application → Offline cumulative update integration → Selective offline driver injection → Offline provisioned-application removal → Offline registry customization → Official unattended OOBE configuration → Manual UEFI boot creation → Manual WinRE registration → Component-store cleanup → Controlled offline first boot → Official complex driver installation → Controlled internet connection → Remaining Windows and Store updates → Final runtimes and settings → Offline WIM capture → Complete-disk FFU capture Is this necessary for most people? Absolutely not. The normal Microsoft installer is sufficient for almost everyone. But for someone who is obsessed with understanding, controlling, and perfecting every stage of a Windows installation, this is the closest I have reached to an absolutely clean, official, and reproducible system. The best part is that I can now use Windows freely, install experimental software, and potentially break things without worrying about repeating the entire process. My final FFU image preserves the complete perfect state. I only need to restore it, and I am back where I started. Important notes Always verify the physical-disk number before using DiskPart or FFU commands. Selecting the wrong disk can destroy data. Test the FFU restoration before treating it as your only backup. FFU images are less flexible than WIM images and are best suited to the same machine, disk layout, or compatible target storage. The target disk generally needs enough capacity for the captured layout. Some driver installers should not be replaced with blind INF injection. Windows 10 and Windows 11 do not always use identical package names, updates, or unattended settings. Remove answer files containing passwords after Windows Setup completes. Keep personal files backed up separately. A system image is not a substitute for a separate data backup. I am interested in hearing how deployment specialists would improve this workflow, and whether anyone else has taken the Microsoft-native WinRE, DISM, WIM, and FFU approach this far. submitted by /u/kaidocodm to r/sysadmin [link] [comments]

submitted by /u/heldsteel7 to r/FinOps [link] [comments]

Renewal season is hitting a lot of people and I keep seeing the same pattern: the quote gets escalated before anyone has actually measured what they run. RVTools is free, read-only and takes about twenty minutes with a service account. Here is the checklist I would work through before replying to anyone. Count billed cores, not sockets. The metric moved from per-socket to per physical core. vHost gives you "# CPU" (sockets) and "Cores per CPU". Multiply, sum per site. Then apply two floors, in this order: The historical 16-core-per-socket minimum. An 8-core CPU bills as 16. The 72-core-per-product-per-order-line minimum, which went up from 16 in April 2025. The second one is the one people miss, and it lands on small sites rather than big ones. 16-host cluster, dual 32-core CPUs = 1,024 cores. Neither floor touches it. 3-host edge site, one 16-core CPU per host = 48 real cores, bills at 72. A 50% overpay. 2-host site, dual 8-core CPUs = 32 real cores, floored to 64 by the socket rule, then to 72 by the order-line rule. A 125% overpay on a box in a cupboard. Worth confirming with your reseller whether they can consolidate sites onto one order line, because that changes the answer a lot. Get it in writing. Find what you are licensing for no reason. vInfo, filter Powerstate = poweredOff, sum "In Use MiB". Powered-off VMs still occupy storage and still sit in your capacity planning. vSnapshot, anything with a date older than about 30 days. Those are a production risk as well as reclaimable space. vHealth has a built-in check for possible orphaned VMDKs and zombie files. Provisioned is not consumed, and that is the number that decides your business case. Sum CPUs in vInfo for powered-on VMs, divide by total physical cores from vHost. That is your real vCPU:pCore ratio. Do it against physical cores, not hyperthreaded logical CPUs, because licensing is physical. Then compare three storage numbers that usually get treated as one: provisioned VMDK capacity (vDisk), datastore in-use (vInfo), and guest filesystem consumed (vPartition). The gap between the first and the third is often most of your "capacity". This matters beyond the renewal. Cloud block storage bills on allocated volume size, not what the guest is using, so a thin 2TB VMDK holding 200GB becomes a 2TB bill on day one unless you shrink it first. Sizing any target on provisioned figures will make a migration look far more expensive than it actually is. Gotchas worth knowing before you start: Column names drift between RVTools versions, and older exports say MB where newer ones say MiB. Print your columns before writing any filters. RVTools is a configuration snapshot, not performance history. It cannot tell you utilisation over time. You still want around 30 days of vCenter stats and a P95 per VM before you size anything. Check vDisk for independent/persistent disk mode and RDMs. Both break most snapshot-based migration tooling. Check vMemory for ballooned and swapped. That tells you where you are already past comfortable overcommit. RVTools cannot see inside the guest, so it will not tell you where SQL Server is installed. On some estates the Windows and SQL per-core licensing delta is bigger than the hypervisor saving, and it follows you to whatever you migrate to. Use a dedicated read-only account, not an admin one, and treat the export as sensitive. It is a complete map of your estate. One framing thing. Moving to a managed vSphere offering on a hyperscaler is not an exit, it is a change of landlord. It may still be the right call if you are up against a datacentre lease deadline, but it is worth saying out loud in the writeup before someone else does. Also worth pricing honestly: "renew a smaller, cleaned-up footprint" is a legitimate option, and doing the cleanup makes every other option cheaper too. Curious what ratios other people are finding when they actually pull the numbers. The provisioned-to-consumed gap seems to be the one that surprises people most. submitted by /u/RulezZzOr to r/sysadmin [link] [comments]

submitted by /u/RnadmolyGneeraedt to r/FinOps [link] [comments]

For a small team with a few services, an enterprise checklist can become ceremony without reducing the main risks. My minimum gate would cover a tested rollback, backups with a restore exercise, health and readiness checks, bounded timeouts and retries, an alert owner, log correlation, secret ownership, and a short incident runbook. I would add load testing or multi-region recovery only when the service’s traffic and recovery target justify them. Which item has prevented a real incident for a small team, and which common checklist item has mostly created busywork? submitted by /u/UkrMalt to r/devops [link] [comments]

submitted by /u/Spiritual-Kitchen-79 to r/FinOps [link] [comments]

tldr; my coding agent refused to leak a secret after setting up the toolkit and running it through the wringer. Secrets Manager shipped a "secret safety" skill in the aws-core plugin of Agent Toolkit for AWS . The idea is that an agent can use a secret without ever seeing the plaintext. I ran it against a throwaway secret in a real account with Claude Code, then spent a while trying to get around it. Posting the findings in case it saves someone else the same trial and error. How it actually works, which is two layers not one: A PreToolUse hook that denies the tool call before it executes and hands the agent a message pointing at the safe path. A wrapper called asm-exec plus {{resolve:secretsmanager:...}} dynamic references. The agent's command holds a placeholder, asm-exec resolves it in its own process, and the plaintext never lands in the model's context. I tested ten fetch shapes against the hook. Six denied, four correctly allowed. It catches the CLI fetch, the batch fetch, structured API calls, a boto3 call buried in a script, a curl straight at the local daemon on port 2773, and an inline python3 -c one-liner. It leaves writes, unrelated calls and a plain grep alone. A few things that tripped me up: The skill usually refuses before the hook ever fires. When I just asked for the value in plain language, the agent declined on its own, cited the skill and pointed me at asm-exec . The deny message never appeared because no tool call was attempted. I only saw the hook fire when I insisted it actually run the command. The skill is what changes the agent's mind, the hook is the backstop for when it tries anyway. Hooks load at session start. Install the plugin mid-session, retry, and the secret comes back exactly as before. You have to restart the agent session. This is in the docs but it is easy to miss and it looks like the feature is broken. aws configure agent-toolkit does not install this one. That's the one-command setup for all agents, and it pulls from the skills catalog. The secret-safety skill and the hook only ship with the aws-core plugin, so if you set up via the CLI you don't get the block. I have the steps I took to get this setup in the full blog linked below. The safe path still calls GetSecretValue . It is not read-free. Your identity still needs secretsmanager:GetSecretValue , and the read still lands in CloudTrail. What changes is where the plaintext ends up, not whether the API is called. CloudTrail attribution is nicer than I expected, but not how I first assumed. Reads through the MCP endpoint show invokedBy , sourceIPAddress and userAgent all as aws-mcp.amazonaws.com , so agent reads are trivially separable from your own. The aws:CalledViaAWSMCP context key is a related but separate thing, it is what you write IAM and SCP conditions against rather than a field in the event record. The hook is shape-aware, and the boundary is sharper than the docs suggest. grep get-secret-value ./src is allowed. grep 'aws secretsmanager get-secret-value' ./src is denied, because the CLI pattern is checked before the read-only allowlist applies. Same for rg and echo . I tripped it grepping my own notes for this writeup. Stack: Claude Code on macOS, one throwaway secret with fake values in us-east-1, deleted afterward. See the full walkthrough using Claude Code here Happy to answer questions. If you find a fetch shape it misses, post it. For folks already using the toolkit, if there is something in the developer experience that could be better, tell me and I'll pass it to the team. submitted by /u/j-vogel to r/aws [link] [comments]

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/hadez1999 to r/FinOps [link] [comments]