Hi all,
I wanted to highlight an observation from the recent LGTM deployments.
Until now, the primary focus was on cases where the SRVAPD certificate was not becoming active. However, the newly created Tanium sensor has helped identify another scenario: in some servers, the certificate was already active, but the databases were still not being reported in Lisa’s dashboard.
Further review showed that the detect_db.sh step may not have been triggered by the earlier deployment script, even though the certificate installation was successful. When detect_db.sh was executed manually, the database was detected and reported successfully.
This indicates a possible gap in the earlier deployment flow after certificate activation. The separate issue of certificates not becoming active on some servers is already being tracked and investigated.
The sensor is also being refined further, but this has been a useful catch and may help explain some of the missing database reporting cases.
Here is a clearer and more professional version for the chat group:
Hi all,
I wanted to share an observation from the recent LGTM deployments.
The deployment script first installs and activates the SRVAPD certificate. Once the certificate installation is successful, it is expected to run "detect_db.sh", which configures the TNA entries and completes the remaining setup required to report the database details to Prometheus and Lisa’s dashboard.
Until now, the main focus has been on resolving cases where the certificate was not becoming active. However, with the help of the recently created Tanium sensor, I noticed that in some cases the certificate was already active, but the databases were still not being reported in Lisa’s dashboard.
After reviewing the sensor results more closely, it appears that even where the certificate had been active since April or May, the "detect_db.sh" module may not have been executed by the original deployment script. When "detect_db.sh" was executed manually on these servers, the databases were successfully detected and reported.
This indicates that there may have been an issue in the earlier script flow, where certificate activation was successful but the subsequent "detect_db.sh" step did not run as expected.
The certificate activation failures seen on some other servers are a separate issue and are already being tracked and investigated.
I am sharing a few supporting examples where the certificate installation completed successfully, but manual execution of "detect_db.sh" was required to complete the database onboarding. This was a useful catch from the Tanium sensor.
Further refinement of the sensor is also in progress to account for other known scenarios. I understand this is not a technical troubleshooting group, but I wanted to highlight the observation and the potential gap identified in the earlier deployment flow.
Since Jörgen said he expected the statement “today or tomorrow,” and the message was sent yesterday afternoon, I would wait until later today. Dhirendra has already asked the key follow-up question, so another message from you this morning may look like duplicate chasing.
If nothing arrives by late afternoon, send:
Hi Jörgen, just following up on the formal communication you mentioned yesterday. Could you please share it with Dhirendra and me once available? It would also be helpful if it includes the expected plan and timeline for resolving the capacity constraint. Thanks.
Fix duplicate user entries in RoleSync user list
The updated RoleSync steps currently populate the user list using the Object ID instead of the corresponding user name. As a result, the user name and Object ID comparison does not match correctly, which can lead to duplicate or misleading entries in the generated user list.
There is currently no functional impact, but the output may be confusing for users and could also result in incorrect interpretation at the code level.
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Cosmos DB control-plane and data-plane RBAC | Internal access-request and approval process |
| Built-in and custom roles | Human-user and technical-user onboarding |
| Microsoft Entra ID and managed identities | MIM/Group ID creation and assignment |
| Group-based access management | Role Sync and future Group ID access model |
| Customer-managed keys and Key Vault integration | CMK ownership, Key Vault access and audit evidence |
| RBAC troubleshooting and common errors | Support ownership and escalation process |
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Availability zones and multi-region deployment | BCM initiation and approval process |
| Single-write and multi-write region design | Internal RPO and RTO expectations |
| Automatic and manual failover options | Failover ownership and communication process |
| Continuous backup and point-in-time restore | Restore-request and validation process |
| Failure scenarios and recovery options | Change, incident and escalation requirements |
| Microsoft support process for backend failover | BCM evidence and exercise documentation |
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Request Unit calculation and consumption | Internal cost ownership and reporting |
| Manual versus autoscale throughput | Lower-environment throughput standards |
| Database-level versus container-level throughput | Approval process for high-cost configurations |
| Query, partition-key and indexing impact on RUs | Audit-to-Deny policy lifecycle |
| TTL and storage optimisation | Cost exception and expiry process |
| Monitoring and identifying high-RU operations | Cost tracker and periodic review process |
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Troubleshooting latency and throttling | First-level checks before escalation |
| HTTP 429 errors and SDK retry behaviour | Application-team versus SRE ownership |
| Hot-partition identification | Required information in support tickets |
| Query and indexing optimisation | Internal incident and escalation process |
| Regional preference and SDK configuration | Log, metric and evidence requirements |
| Cosmos DB monitoring and diagnostic tools | GitLab tracking and follow-up ownership |
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Secure Cosmos DB deployment patterns | Internal Control Plane and pipeline workflow |
| Backup, networking, CMK and RBAC configuration | Mandatory policy metadata and category values |
| Private endpoint configuration | CI validation and release requirements |
| Azure Policy effects: Audit, Deny, DINE and AINE | Internal policy review and approval lifecycle |
| ARM, Bicep and Terraform considerations | Policy tracker, evidence and ownership |
| Recommended compliance controls | Exception and remediation process |
| External — Microsoft Product Content | Internal — Bank Process and Governance |
|---|---|
| Account and container migration approaches | Application onboarding and eligibility assessment |
| Container Copy and supported migration tools | Internal approval for Preview features |
| Source-to-target connectivity requirements | Migration Factory engagement process |
| Data validation and reconciliation | Naming and policy-compliance checks |
| Migration performance and RU planning | Production-readiness and change approval |
| Rollback and post-migration validation | Ownership, support and decommissioning process |
Hello Friends! I am aliena part time blogger from Bihar. I am a student and I manage my study as well as my blog. I am 14 years old and I want to help those people who really want to do something on internet.
Copyright © 201. Metro UI Theme. Designed by: Templateism
