docs(misc): Change to stylized note/warning/important banners

docs/enhanced-configuration/gitops.md

@@ -44,9 +44,10 @@ References:
 
 Afterwards, you can use the resulting manifests within a standard Argo CD workflow.
 
-> **Note**<br>
-> When creating the Argo CD application based on the resulting manifests, you must not use the `Automated Sync Policy`
-> offered by Argo CD, as you have to manually ensure the applications are updated in the required sequence.
+> [!note]
+> When creating the Argo CD application based on the resulting manifests, you must not use the `Automated Sync
+> Policy` offered by Argo CD, as you have to manually ensure the applications are updated in the required
+> sequence.
 
 ## Option 2: Helmfile plugin
 

docs/enhanced-configuration/groupware-migration.md

@@ -41,8 +41,9 @@ You will have to select an existing user account that will be used as a service
 
 Please note that the account that shall serve as the service account requires a Microsoft 365/Exchange online license (mailbox).
 
-> **Note**<br>
-> If you want to designate your admin account as a service account, you have to provide the admin with a license.
+> [!note]
+> If you want to designate your admin account as a service account, you have to provide the admin with a
+> license.
 
 ***2. Register the audriga app in your tenant***
 
@@ -53,7 +54,7 @@ To register the audriga app in your tenant, log into your admin account and acce
 - Accept the App "audriga CloudMovr migration"
 - You will be redirected to an audriga page, which you can close - it does not require additional interaction.
 
-> **Note**<br>
+> [!note]
 > The audriga application is created under the "Enterprise application" tab in the AzureAD console.
 
 ***3. Create a "secret" group in the M365 tenant***
@@ -91,11 +92,15 @@ To validate the master authentication mode please read the appendix section at t
 
 Updating your deployment with these settings will allow you to continue with the migration scenario. Once the migration is completed, you can remove `secrets.oxAppSuite.migrationsMasterPassword` and need to turn off the migration mode by setting `functional.migration.oxAppSuite.enabled` to `false` or removing that setting, as `false` is the default before you update your deployment once again.
 
-> **Note**<br>
-> For the changes to take effect, it is sufficient to re-deploy the `open-xchange` component alone. But you have to restart the Dovecot Pod(s) manually when switching to/from the master authentication mode for the changes to take effect.
+> [!note]
+> For the changes to take effect, it is sufficient to re-deploy the `open-xchange` component alone. But you
+> have to restart the Dovecot Pod(s) manually when switching to/from the master authentication mode for the
+> changes to take effect.
 
-> **Note**<br>
-> While in master authentication mode, regular users cannot log in to the webmail module of openDesk or access the mail using IMAP, as it is not recommended that users interact with the target mail infrastructure during the migration scenario described in this document.
+> [!note]
+> While in master authentication mode, regular users cannot log in to the webmail module of openDesk or access
+> the mail using IMAP, as it is not recommended that users interact with the target mail infrastructure during
+> the migration scenario described in this document.
 
 # Migration configuration
 
@@ -107,7 +112,7 @@ Ensure you meet the prerequisites. For example, this document does not support u
 
 Choose [Microsoft 365 / Exchange Online (Admin)](https://umzug.audriga.com/SMESwitchWebApp/?client=groupware#src=onmicrosoft.com) as your current provider.
 
-> **Note**<br>
+> [!note]
 > You may need to start typing in "Microsoft Office 365/Exchange Online" for it to appear in the list.
 
 Configure openDesk as your destination server:

docs/enhanced-configuration/idp-federation.md

@@ -152,7 +152,7 @@ If you just created the `fed-test-idp-realm`, you are already in the admin scree
 
 ## openDesk IdP
 
-> **Note**
+> [!note]
 > While manual configuration is possible, an SSO federation can also be configured as part of the deployment.
 > Check `functional.authentication.ssoFederation` section from the `functional.yaml.gotmpl` for details.
 

docs/enhanced-configuration/self-signed-certificates.md

@@ -52,9 +52,9 @@ CA certificate as X.509 encoded (`ca.crt`) and as jks trust store (`truststore.j
 5. Create a Kubernetes secret with name `opendesk-certificates-keystore-jks` with key `password` and as value the jks
 trust store password.
 
-> **Note**<br>
-> XWiki does not support the use of an existing secret to access the keystore. Therefore you have to set the password
-> from step 5 also as `secrets.certificates.password`.
+> [!note]
+> XWiki does not support the use of an existing secret to access the keystore. Therefore you have to set the
+> password from step 5 also as `secrets.certificates.password`.
 
 ## Option 2a: Use cert-manager.io with auto-generated namespace based root-certificate