Revert "Revert "EndofFeature-MigrationGuide""

Author: alfpark

articles/batch/TOC.yml

@@ -111,6 +111,10 @@
       href: batch-certificate-migration-guide.md
     - name: Pools without public IP addresses (classic)
       href: batch-pools-without-public-IP-addresses-classic-retirement-migration-guide.md
+    - name: Classic compute node communication model
+      href: batch-pools-to-simplified-compute-node-communication-model-migration-guide.md
+    - name: VHD and Managed Images
+      href: batch-custom-image-pools-to-azure-compute-gallery-migration-guide.md
     - name: TLS 1.0 and TLS 1.1
       href: batch-tls-101-migration-guide.md
     - name: Job and pool lifetime statistics

articles/batch/batch-custom-image-pools-to-azure-compute-gallery-migration-guide.md

@@ -0,0 +1,60 @@
+---
+title: Migrate Azure Batch Custom Image Pools to Azure Compute Gallery
+description: Learn how to migrate Azure Batch custom image pools to Azure compute gallery and plan for feature end of support.
+author: harperche
+ms.author: harpercheng
+ms.service: batch
+ms.topic: how-to
+ms.date: 02/23/2023
+---
+
+# Migrate Azure Batch custom image pools to Azure Compute Gallery 
+
+To improve reliability, scale, and align with modern Azure offerings, Azure Batch will retire custom image Batch pools specified from virtual hard disk (VHD) blobs in Azure Storage and Azure Managed Images on *March 31, 2024*. Learn how to migrate your Azure Batch custom image pools using Azure Compute Gallery.
+
+
+## Feature end of support
+
+When you create an Azure Batch pool using the Virtual Machine Configuration, you specify an image reference that provides the operating system for each compute node in the pool. You can create a pool of virtual machines either with a supported Azure Marketplace image or with a custom image. Custom images from VHD blobs and managed Images are either legacy offerings or non-scalable solutions for Azure Batch. To ensure reliable infrastructure provisioning at scale, all custom image sources other than Azure Compute Gallery will be retired on *March 31, 2024*.
+
+## Alternative: Use Azure Compute Gallery references for Batch custom image pools
+
+When you use the Azure Compute Gallery (formerly known as Shared Image Gallery) for your custom image, you have control over the operating system type and configuration, as well as the type of data disks. Your shared image can include applications and reference data that become available on all the Batch pool nodes as soon as they're provisioned. You can also have multiple versions of an image as needed for your environment. When you use an image version to create a VM, the image version is used to create new disks for the VM.
+
+Using a shared image saves time in preparing your pool's compute nodes to run your Batch workload. It's possible to use an Azure Marketplace image and install software on each compute node after provisioning, but using a shared image can lead to more efficiencies, in faster compute node to ready state and reproducible workloads. Additionally, you can specify multiple replicas for the shared image so when you create pools with many compute nodes, provisioning latencies can be lower.
+
+## Migrate Your Eligible Pools
+
+To migrate your Batch custom image pools from managed image to shared image, review the Azure Batch guide on using [Azure Compute Gallery to create a custom image pool](batch-sig-images.md).
+
+If you have either a VHD blob or a managed image, you can convert them directly to a Compute Gallery image that can be used with Azure Batch custom image pools. When you're creating a VM image definition for a Compute Gallery, on the Version tab, there is an option to select the source for image types to migrate that're being retired for Batch custom image pools:
+
+| Source | Other fields |
+|---|---|
+| Managed image | Select the **Source image** from the drop-down. The managed image must be in the same region that you chose in **Instance details.** |
+| VHD in a storage account | Select **Browse** to choose the storage account for the VHD. |
+
+For more information about this process, see [creating an image definition and version for Compute Gallery](../virtual-machines/image-version.md#create-an-image).
+
+## FAQs
+
+- How can I create an Azure Compute Gallery?
+
+  See the [guide](../virtual-machines/create-gallery.md#create-a-private-gallery) for Compute Gallery creation.
+
+- How do I create a Pool with a Compute Gallery image?
+
+  See the [guide](batch-sig-images.md) for creating a Pool with a Compute Gallery image.
+
+- What considerations are there for Compute Gallery image based Pools?
+
+  See the [guide](batch-sig-images.md#considerations-for-large-pools) for more information.
+
+- Can I use Azure Compute Gallery images in different subscriptions or in different Azure AD tenants?
+  
+  If the Shared Image is not in the same subscription as the Batch account, you must register the Microsoft.Batch resource provider for that subscription. The two subscriptions must be in the same Azure AD tenant. The image can be in a different region as long as it has replicas in the same region as your Batch account.
+
+
+## Next steps
+
+For more information, see [Azure Compute Gallery](../virtual-machines/azure-compute-gallery.md).

articles/batch/batch-pools-to-simplified-compute-node-communication-model-migration-guide.md

@@ -0,0 +1,60 @@
+---
+title: Migrate Azure Batch pools to the Simplified compute node communication model
+description: Learn how to migrate Azure Batch pools to the simplified compute node communication model and plan for feature end of support.
+author: harperche
+ms.author: harpercheng
+ms.service: batch
+ms.topic: how-to
+ms.date: 02/23/2023
+---
+
+# Migrate Azure Batch pools to the Simplified compute node communication model 
+
+To improve security, simplify the user experience, and enable key future improvements, Azure Batch will retire the classic compute node communication model on *March 31, 2026*. Learn how to migrate your Batch pools to using the simplified compute node communication model.
+
+
+## About the feature
+
+An Azure Batch pool contains one or more compute nodes, which execute user-specified workloads in the form of Batch tasks. To enable Batch functionality and Batch pool infrastructure management, compute nodes must communicate with the Azure Batch service. In the Classic compute node communication model, the Batch service initiates communication to the compute nodes and compute nodes must be able to communicate with Azure Storage for baseline operations. In the Simplified compute node communication model, Batch pools only require outbound access to the Batch service for baseline operations.
+
+## Feature end of support
+
+The simplified compute node communication model will replace the classic compute node communication model after *March 31, 2026*.  The change is introduced in two phases. From now until *September 30, 2024*, the default node communication mode for newly created [Batch pools with virtual networks](./batch-virtual-network.md) will remain as classic. After *September 30, 2024*, the default node communication mode for newly created Batch pools with virtual networks will switch to the simplified. After *March 31, 2026*, the option to use classic compute node communication mode will no longer be honored. Batch pools without user-specified virtual networks are  unaffected by this change and the default communication mode is controlled by the Batch service.
+
+## Alternative: Use Simplified Compute Node Communication Model
+
+The simplified compute node communication mode streamlines the way Batch pool infrastructure is managed on behalf of users. This communication mode reduces the complexity and scope of inbound and outbound networking connections required in the baseline operations.
+
+The simplified model also provides more fine-grained data exfiltration control, since outbound communication to *Storage.region* is no longer required. You can explicitly lock down outbound communication to Azure Storage if necessary for your workflow (such as AppPackage storage accounts, other storage accounts for resource files or output files, or other similar scenarios).
+
+## Migrate Your Eligible Pools
+
+To migrate your Batch pools from classic to the simplified compute node communication model, please follow this document from the section entitled [potential impact between classic and simplified communication modes](simplified-compute-node-communication.md#potential-impact-between-classic-and-simplified-communication-modes) to either create new pools or update existing pools with simplified compute node communication.
+
+## FAQs
+
+- Will I still require a public IP address for my nodes?
+
+  The public IP address is still needed to initiate the outbound connection to Azure Batch. If you want to eliminate the need for public IP addresses entirely, see the guide to [create a simplified node communication pool without public IP addresses](./simplified-node-communication-pool-no-public-ip.md)
+
+- How can I connect to my nodes for diagnostic purposes?
+
+  RDP or SSH connectivity to the node is unaffected – load balancer(s) will still be created which can route those requests through to the node when provisioned with a public IP address.
+
+- What differences will I see in billing?
+
+  There should be no cost or billing implications for the new model.
+
+- Are there any changes to agents on the compute node?
+  
+  An extra agent will be running on compute nodes for both Windows and Linux, azbatch-cluster-agent.
+
+- Will there be any change to how my linked resources from Azure Storage in Batch pools and tasks are downloaded?
+
+  This behavior is unaffected – all user-specified resources that require Azure Storage such as resource files, output files, or application packages will still be made from the compute node directly to Azure Storage. You'll need to ensure your networking configuration allows these flows.
+
+
+## Next steps
+
+For more information, see [Simplified compute node communication](./simplified-compute-node-communication.md).
+