Business Central načasování aktualizací

Při plánování aktualizací pro Dynamics 365 Business Central (online) administrátoři jako já často narazí na rozdíl mezi datem naplánované aktualizace v e-mailech, v datu zobrazeném v BC Admin Center a z notifikace o provedené aktualizace. To může být matoucí – zejména pokud se rozdíl zdá být celý jeden den. 

Všechna nastavení okna pro aktualizaci v Centru pro správu jsou v místním čase. Administrátoři konfigurují:

• Naplánované datum aktualizace.

• Čas začátku a konce okna pro aktualizaci (v místním časovém pásmu). 

Business Central interně převádí místní čas pro aktualizaci do UTC zóny. 

Dokumentace Microsoftu uvádí:

• Okno pro aktualizaci se zadává v místním čase.

• Systém však vyhodnocuje a spouští aktualizaci pomocí UTC.

• To znamená, že plánovač používá verzi okna převedenou na UTC, i když vy v portálu vidíte místní čas.

Business Central spustí aktualizaci, jakmile jsou splněny obě podmínky:

1. V čase UTC nastalo naplánované datum.

2. Aktuální čas UTC spadá do okna pro aktualizaci převedeného na UTC.

Neexistuje žádné pravidlo, které by říkalo, že BC čeká na místní kalendářní datum. Relevantní hranicí je půlnoc UTC, nikoliv místní půlnoc.

Proč uživatelé někdy vidí aktualizace běžet lokálně „dříve“?

Protože se datum i okno pro aktualizaci vyhodnocují v UTC, může aktualizace začít dříve, než začne místní naplánované datum, pokud:

• Naplánované datum v UTC nastalo dříve než v místním čase.

• Převedené okno v UTC se překrývá s předchozím místním dnem.

Toto není chyba – je to přímý důsledek plánovací logiky.

Příklad 1

• Naplánované datum (místní): 14. února 
• Okno (místní): 00:00–06:00
• Místní časové pásmo: UTC+02 
• $převod$
• $00:00\; na\; 22:00\text{ UTC (předchozí den)}$ 
• 06:00 na 04:00 UTC (stejný den)

Tudíž okno v UTC je: 22:00 UTC 13. února $\to$ 04:00 UTC 14. února

Kdy může BC začít? Jakmile nastane v UTC 14. února, což se stane ve 02:00 místního času (UTC+02), a zároveň je čas UTC uvnitř převedeného okna. Protože se okno v UTC otevírá už ve 22:00 UTC předchozího dne, může se to překrývat s předchozím místním večerem nebo brzkým ránem.

Centrum pro správu ukazove 15. února: Panel zobrazuje místní den, ve kterém okno pro aktualizaci probíhá. Pokud okno překračuje místní půlnoc, může se toto datum jevit jako posunuté. Vyplývá to z faktu, že okno pro aktualizaci zasahuje do dvou různých místních kalendářních dnů.

Příklad 2

• Naplánované datum aktualizace: 24. září
• Okno pro aktualizaci (místní CST, UTC-6): 21:00 → 04:00 
• Převod okna na UTC:
• 21:00 CST = 03:00 UTC (následující den) 
• 04:00 CST=10:00 UTC (stejný​ den)

Tudíž okno v UTC je: 03:00 $\to$ 10:00 UTC dne 25. září

Kdy BC uvidí naplánované datum? Naplánované datum 24. září v UTC nastane mnohem dříve, než nastane 24. září v CST.

Kdy BC spustí aktualizaci? V první moment, kdy jsou obě podmínky pravdivé:

1. Datum UTC $\ge$ 24. září.
2. Aktuální čas UTC je mezi 03:00 a 10:00 UTC (25. září UTC).

Protože 03:00 UTC dne 25. září odpovídá 22:00 CST dne 23. září, BC zcela legitimně zahájí aktualizaci: 23. září ve 22:19 CST.

Není to brzy – je to správně podle:

• Začátku data UTC.
• Okna převedeného na UTC.

Azure Performance Diagnostics Extension deployment failed

I got the following error when deploying AzPerfDiagExtension via Azure Portal

"VMExtensionProvisioningError", "message": "VM has reported a failure when processing extension 'AzurePerformanceDiagnostics' (publisher 'Microsoft.Azure.Performance.Diagnostics' and type 'AzurePerformanceDiagnostics'). Error message: 'Failed to enable extension 'AzPerfDiagExtension' because either the storage account name or key provided is invalid. Please re-install extension 'AzPerfDiagExtension' using a valid storage account name and key or install Performance Diagnostics by navigating to the VM -> Help -> Performance Diagnostics blade.'. More information on troubleshooting is available at https://aka.ms/vmextensionwindowstroubleshoot. "

There are two blades how to initiate PerfDiag installation. One is to add an extension to the VM, and the second is to scroll down to the independent tab "Performance Diagnostics" in the Help column of the virtual machine.

It offers to use storage keys and managed identity. I could list SAK so I expected at least this option working but it wasn't. My role was "only" contributor so I was expecting an error coming from some permission issue.

Here are the permissions needed listed to Run Performance Diagnostics.

• The Owner role on the VM and an Azure role that includes the Microsoft.Storage/storageAccounts/listkeys/action permission on the storage account

I requested owner role for VM and I got it. The issue is that I am owner for my user account, but that isn't affecting relation between the VM and the storage account. What I did to fix the problem is to assign permissions of owner" (actually somehting less should be better) for the managed identity of the VM via IAM configuration.

Once again I granted permissions via IAM to storage account for the managed identity of the VM, not for myself as user. It wasn't obvious to me that it is needed like this and I spent some time trying to figure out what it was.

What is interesting on this solution is that I previously tried to configure performance diagnostic with manual storage account name and SAK insertion to the Azure portal installation wizard (for VM Extension installation) but it failed as many time before.

What was tried (before granting permission for SA to managed identity of the VM)

1. Copied fresh keys from the Storage account “Access keys” blade and manually pasted into the extension protected settings (not using connection strings).
2. Explicitly set authenticationType: StorageKey.
3. Confirmed account name syntax (lowercase, alphanumeric).
4. Verified region match (VM and storage in same Azure region).
5. Ensured network access (public “All networks”).
6. Retried installation through both Support + troubleshooting → Performance diagnostics blade and extension install path.

The error might have more verbose version from Performance diagnostic blade

Failed to retrieve storage account information for performance diagnostics. Try reinstalling performance diagnostics. Error details: {"name":"StorageError","message":"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.\n
"xhr":{"status":403,"statusText":"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.","responseText":"{\"odata.error\":{\"code\":\"AuthenticationFailed\",\"message\":{\"lang\":\"en-US\",\"value\":\"Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.\"}}}"}}} {"name":"StorageError","message":"The table specified does not exist\n
"status":404,"statusText":"Not Found","responseText":"{\"odata.error\":{\"code\":\"TableNotFound\",\"message\":{\"lang\":\"en-US\",\"value\":\"The table specified does not exist.\"}}}"}}}