You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# How to enable Microsoft Authenticator Lite for Outlook mobile (preview)
21
21
22
-
>[!NOTE]
23
-
>Rollout has not yet completed across Outlook applications. If this feature is enabled in your tenant, your users may not yet be prompted for the experience. To minimize user disruption, we recommend enabling this feature when the rollout completes.
24
22
25
23
Microsoft Authenticator Lite is another surface for Azure Active Directory (Azure AD) users to complete multifactor authentication by using push notifications or time-based one-time passcodes (TOTP) on their Android or iOS device. With Authenticator Lite, users can satisfy a multifactor authentication requirement from the convenience of a familiar app. Authenticator Lite is currently enabled in [Outlook mobile](https://www.microsoft.com/microsoft-365/outlook-mobile-for-android-and-ios).
26
24
@@ -38,8 +36,8 @@ Users receive a notification in Outlook mobile to approve or deny sign-in, or th
38
36
39
37
| Operating system | Outlook version |
40
38
|:----------------:|:---------------:|
41
-
|Android | 4.2309.1 |
42
-
|iOS | 4.2309.0|
39
+
|Android | 4.2310.1 |
40
+
|iOS | 4.2312.1|
43
41
44
42
## Enable Authenticator Lite
45
43
@@ -52,7 +50,8 @@ By default, Authenticator Lite is [Microsoft managed](concept-authentication-def
52
50
53
51
To enable Authenticator Lite in the Azure portal, complete the following steps:
54
52
55
-
1. In the Azure portal, click Security > Authentication methods > Microsoft Authenticator.
53
+
1. In the Azure portal, click Azure Active Directory > Security > Authentication methods > Microsoft Authenticator.
54
+
In the Entra admin center, on the sidebar select Azure Active Directory > Protect & Secure > Authentication methods > Microsoft Authenticator.
56
55
57
56
2. On the Enable and Target tab, click Yes and All users to enable the policy for everyone or add selected users and groups. Set the Authentication mode for these users/groups to Any or Push.
Copy file name to clipboardExpand all lines: articles/aks/auto-upgrade-cluster.md
+17-9Lines changed: 17 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,13 +20,21 @@ Part of the AKS cluster lifecycle involves performing periodic upgrades to the l
20
20
21
21
Cluster auto-upgrade provides a set once and forget mechanism that yields tangible time and operational cost benefits. By enabling auto-upgrade, you can ensure your clusters are up to date and don't miss the latest AKS features or patches from AKS and upstream Kubernetes.
22
22
23
-
AKS follows a strict versioning window with regard to supportability. With properly selected auto-upgrade channels, you can avoid clusters falling into an unsupported version. For more on the AKS support window, see [Alias minor versions][supported-kubernetes-versions].
23
+
AKS follows a strict supportability versioning window. With properly selected auto-upgrade channels, you can avoid clusters falling into an unsupported version. For more on the AKS support window, see [Alias minor versions][supported-kubernetes-versions].
24
+
25
+
## Customer versus AKS-initiated auto-upgrades
26
+
27
+
Customers can specify cluster auto-upgrade specifics in the following guidance. These upgrades occur based on the cadence the customer specifies and are recommended for customers to remain on supported Kubernetes versions.
28
+
29
+
AKS also initiates auto-upgrades for unsupported clusters. When a cluster in an n-3 version (where n is the latest supported AKS GA minor version) is about to drop to n-4, AKS automatically upgrades the cluster to n-2 to remain in an AKS support [policy][supported-kubernetes-versions]. Automatically upgrading a platform supported cluster to a supported version is enabled by default.
30
+
31
+
For example, Kubernetes v1.25 will upgrade to v1.26 during the v1.29 GA release. To minimize disruptions, set up [maintenance windows][planned-maintenance].
24
32
25
33
## Cluster auto-upgrade limitations
26
34
27
-
If you’re using cluster auto-upgrade, you can no longer upgrade the control plane first and then upgrade the individual node pools. Cluster auto-upgrade will always upgrade the control plane and the node pools together. There is no ability of upgrading the control plane only, and trying to run the command `az aks upgrade --control-plane-only`will raise the error: `NotAllAgentPoolOrchestratorVersionSpecifiedAndUnchanged: Using managed cluster api, all Agent pools' OrchestratorVersion must be all specified or all unspecified. If all specified, they must be stay unchanged or the same with control plane.`
35
+
If you’re using cluster auto-upgrade, you can no longer upgrade the control plane first, and then upgrade the individual node pools. Cluster auto-upgrade always upgrades the control plane and the node pools together. There's no ability of upgrading the control plane only, and trying to run the command `az aks upgrade --control-plane-only`raises the following error: `NotAllAgentPoolOrchestratorVersionSpecifiedAndUnchanged: Using managed cluster api, all Agent pools' OrchestratorVersion must be all specified or all unspecified. If all specified, they must be stay unchanged or the same with control plane.`
28
36
29
-
If using the `node-image` cluster auto-upgrade channel or the `NodeImage` node image auto-upgrade channel, Linux [unattended upgrades][unattended-upgrades]will be disabled by default.
37
+
If using the `node-image` cluster auto-upgrade channel or the `NodeImage` node image auto-upgrade channel, Linux [unattended upgrades][unattended-upgrades]is disabled by default.
30
38
31
39
## Using cluster auto-upgrade
32
40
@@ -40,7 +48,7 @@ The following upgrade channels are available:
40
48
|`patch`| automatically upgrade the cluster to the latest supported patch version when it becomes available while keeping the minor version the same.| For example, if a cluster is running version *1.17.7* and versions *1.17.9*, *1.18.4*, *1.18.6*, and *1.19.1* are available, your cluster is upgraded to *1.17.9*|
41
49
| `stable`| automatically upgrade the cluster to the latest supported patch release on minor version *N-1*, where *N* is the latest supported minor version.| For example, if a cluster is running version *1.17.7* and versions *1.17.9*, *1.18.4*, *1.18.6*, and *1.19.1* are available, your cluster is upgraded to *1.18.6*.
42
50
| `rapid`| automatically upgrade the cluster to the latest supported patch release on the latest supported minor version.| In cases where the cluster is at a version of Kubernetes that is at an *N-2* minor version where *N* is the latest supported minor version, the cluster first upgrades to the latest supported patch version on *N-1* minor version. For example, if a cluster is running version *1.17.7* and versions *1.17.9*, *1.18.4*, *1.18.6*, and *1.19.1* are available, your cluster first is upgraded to *1.18.6*, then is upgraded to *1.19.1*.
43
-
|`node-image`| automatically upgrade the node image to the latest version available.| Microsoft provides patches and new images for image nodes frequently (usually weekly), but your running nodes won't get the new images unless you do a node image upgrade. Turning on the node-image channel will automatically update your node images whenever a new version is available. If you use this channel, Linux [unattended upgrades]will be disabled by default.|
51
+
|`node-image`| automatically upgrade the node image to the latest version available.| Microsoft provides patches and new images for image nodes frequently (usually weekly), but your running nodes don't get the new images unless you do a node image upgrade. Turning on the node-image channel automatically updates your node images whenever a new version is available. If you use this channel, Linux [unattended upgrades]are disabled by default.|
44
52
45
53
> [!NOTE]
46
54
> Cluster auto-upgrade only updates to GA versions of Kubernetes and will not update to preview versions.
@@ -78,7 +86,7 @@ The Azure portal also highlights all the deprecated APIs between your current ve
78
86
79
87
## Using auto-upgrade with Planned Maintenance
80
88
81
-
If you’re using Planned Maintenance and cluster auto-upgrade, your upgrade will start during your specified maintenance window.
89
+
If you’re using Planned Maintenance and cluster auto-upgrade, your upgrade starts during your specified maintenance window.
82
90
83
91
> [!NOTE]
84
92
> To ensure proper functionality, use a maintenance window of four hours or more.
@@ -87,7 +95,7 @@ For more information on Planned Maintenance, see [Use Planned Maintenance to sch
87
95
88
96
## Best practices for cluster auto-upgrade
89
97
90
-
The following best practices will help maximize your success when using auto-upgrade:
98
+
Use the following best practices to help maximize your success when using auto-upgrade:
91
99
92
100
- In order to keep your cluster always in a supported version (i.e within the N-2 rule), choose either `stable` or `rapid` channels.
93
101
- If you're interested in getting the latest patches as soon as possible, use the `patch` channel. The `node-image` channel is a good fit if you want your agent pools to always be running the most recent node images.
@@ -96,9 +104,9 @@ The following best practices will help maximize your success when using auto-upg
96
104
- Follow [PDB best practices][pdb-best-practices].
Copy file name to clipboardExpand all lines: articles/aks/faq.md
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -177,6 +177,18 @@ Most clusters are deleted upon user request; in some cases, especially where cus
177
177
178
178
No, you're unable to restore your cluster after deleting it. When you delete your cluster, the associated resource group and all its resources will also be deleted. If you want to keep any of your resources, move them to another resource group before deleting your cluster. If you have the **Owner** or **User Access Administrator** built-in role, you can lock Azure resources to protect them from accidental deletions and modifications. For more information, see [Lock your resources to protect your infrastructure][lock-azure-resources].
179
179
180
+
## What is platform support, and what does it include?
181
+
182
+
Platform support is a reduced support plan for unsupported "N-3" version clusters. Platform support only includes Azure infrastructure support. Platform support does not include anything related to Kubernetes functionality and components, cluster or node pool creation, hotfixes, bug fixes, security patches, retired components, etc. See [platform support policy][supported-kubernetes-versions] for additional restrictions.
183
+
184
+
AKS relies on the releases and patches from [Kubernetes](https://kubernetes.io/releases/), which is an Open Source project that only supports a sliding window of 3 minor versions. AKS can only guarantee [full support](./supported-kubernetes-versions.md#kubernetes-version-support-policy) while those versions are being serviced upstream. Since there's no more patches being produced upstream, AKS can either leave those versions unpatched or fork. Due to this limitation, platform support will not support anything from relying on kubernetes upstream.
185
+
186
+
## Will AKS automatically upgrade my unsupported clusters?
187
+
188
+
AKS will initiate auto-upgrades for unsupported clusters. When a cluster in an n-3 version (where n is the latest supported AKS GA minor version) is about to drop to n-4, AKS will automatically upgrade the cluster to n-2 to remain in an AKS support [policy][supported-kubernetes-versions]. Automatically upgrading a platform supported cluster to a supported version is enabled by default.
189
+
190
+
For example, kubernetes v1.25 will be upgraded to v1.26 during the v1.29 GA release. To minimize disruptions, set up [maintenance windows][planned-maintenance]. See [auto-upgrade][auto-upgrade-cluster] for details on automatic upgrade channels.
191
+
180
192
## If I have pod / deployments in state 'NodeLost' or 'Unknown' can I still upgrade my cluster?
181
193
182
194
You can, but we don't recommend it. Upgrades should be performed when the state of the cluster is known and healthy.
@@ -333,6 +345,8 @@ The extension **does not** require any additional outbound access to any URLs, I
Copy file name to clipboardExpand all lines: articles/aks/supported-kubernetes-versions.md
+37Lines changed: 37 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,6 +83,8 @@ AKS defines a generally available (GA) version as a version available in all reg
83
83
84
84
AKS may also support preview versions, which are explicitly labeled and subject to [preview terms and conditions][preview-terms].
85
85
86
+
AKS provides platform support only for one GA minor version of Kubernetes after the regular supported versions. The platform support window of Kubernetes versions on AKS is known as "N-3". For more information, see [platform support policy](#platform-support-policy).
87
+
86
88
> [!NOTE]
87
89
> AKS uses safe deployment practices which involve gradual region deployment. This means it may take up to 10 business days for a new release or a new version to be available in all regions.
88
90
@@ -128,6 +130,41 @@ New Supported Version List
128
130
1.17.*9*, 1.17.*8*, 1.16.*11*, 1.16.*10*
129
131
```
130
132
133
+
## Platform support policy
134
+
135
+
Platform support policy is a reduced support plan for certain unsupported kubernetes versions. During platform support, customers will only receive support from Microsoft for AKS/Azure platform related issues. Any issues related to Kubernetes functionality and components will not be supported.
136
+
137
+
Platform support policy applies to clusters in an n-3 version (where n is the latest supported AKS GA minor version), before the cluster drops to n-4. For example, kubernetes v1.25 will be considered platform support when v1.28 is the latest GA version. However, during the v1.29 GA release, v1.25 will then be auto-upgraded to v1.26.
138
+
139
+
AKS relies on the releases and patches from [kubernetes](https://kubernetes.io/releases/), which is an Open Source project that only supports a sliding window of 3 minor versions. AKS can only guarantee [full support](#kubernetes-version-support-policy) while those versions are being serviced upstream. Since there's no more patches being produced upstream, AKS can either leave those versions unpatched or fork. Due to this limitation, platform support will not support anything from relying on kubernetes upstream.
140
+
141
+
This table outlines support guidelines for Community Support compared to Platform support.
142
+
143
+
| Support category | Community Support (N-2) | Platform Support (N-3) |
144
+
|---|---|---|
145
+
| Upgrades from N-3 to a supported version| Supported | Supported|
| Storage, Networking related issues| Supported | Supported with the exception of bug fixes and retired components |
150
+
| Start/stop | Supported | Supported|
151
+
| Rotate certificates | Supported | Supported|
152
+
| Infrastructure SLA| Supported | Supported|
153
+
| Control Plane SLA| Supported | Supported|
154
+
| Platform (AKS) SLA| Supported | Not supported|
155
+
| Kubernetes components (including Add-ons) | Supported | Not supported|
156
+
| Component updates | Supported | Not supported|
157
+
| Component hotfixes | Supported | Not supported|
158
+
| Applying bug fixes | Supported | Not supported|
159
+
| Applying security patches | Supported | Not supported|
160
+
| Kubernetes API support | Supported | Not supported|
161
+
| Cluster or node pool creation| Supported | Not supported|
162
+
| Node pool snapshot| Supported | Not supported|
163
+
| Node image upgrade| Supported | Not supported|
164
+
165
+
> [!NOTE]
166
+
> The above table is subject to change and outlines common support scenarios. Any scenarios related to Kubernetes functionality and components will not be supported for N-3. For further support, see [Support and troubleshooting for AKS](./aks-support-help.md).
167
+
131
168
### Supported `kubectl` versions
132
169
133
170
You can use one minor version older or newer of `kubectl` relative to your *kube-apiserver* version, consistent with the [Kubernetes support policy for kubectl](https://kubernetes.io/docs/setup/release/version-skew-policy/#kubectl).
@@ -135,18 +135,18 @@ The `publish` command adds a module to a registry. The Azure container registry
135
135
136
136
After publishing the file to the registry, you can [reference it in a module](modules.md#file-in-registry).
137
137
138
-
To use the publish command, you must have Bicep CLI version **0.4.1008 or later**.
138
+
To use the publish command, you must have Bicep CLI version **0.4.1008 or later**. To use the `--documentationUri`/`-d` parameter, you must have Bicep CLI version **0.14.46 or later**.
139
139
140
140
To publish a module to a registry, use:
141
141
142
142
```azurecli
143
-
az bicep publish --file <bicep-file> --target br:<registry-name>.azurecr.io/<module-path>:<tag>
143
+
az bicep publish --file <bicep-file> --target br:<registry-name>.azurecr.io/<module-path>:<tag> --documentationUri <documentation-uri>
144
144
```
145
145
146
146
For example:
147
147
148
148
```azurecli
149
-
az bicep publish --file storage.bicep --target br:exampleregistry.azurecr.io/bicep/modules/storage:v1
149
+
az bicep publish --file storage.bicep --target br:exampleregistry.azurecr.io/bicep/modules/storage:v1 --documentationUri https://www.contoso.com/exampleregistry.html
150
150
```
151
151
152
152
The `publish` command doesn't recognize aliases that you've defined in a [bicepconfig.json](bicep-config-modules.md) file. Provide the full module path.
0 commit comments