Merge pull request #180579 from Blackmist/1885517-file-store

removing limitation per PM feedback

Author: PRMerger17

articles/machine-learning/concept-network-data-access.md

@@ -66,11 +66,6 @@ When using an Azure Storage Account from Azure Machine Learning studio, you must
 For more information, see [Use Azure Machine Learning studio in an Azure Virtual Network](how-to-enable-studio-virtual-network.md).
 
 See the following sections for information on limitations when using Azure Storage Account with your workspace in a VNet.
-### Using an existing storage account
-
-If you use an existing storage account as the __default storage__ when creating a workspace, the `azureml-filestore` folder in the file store doesn't automatically get created. This folder is required when submitting [AutoML](concept-automated-ml.md) experiments.
-
-To avoid this issue, you can either allow Azure Machine Learning to create the default storage for you when creating the workspace or make sure the existing storage account  is __not__ in the VNet when creating the workspace. For more information on networking with Azure Storage Account, see [Configure Azure Storage Accounts with virtual networks](../storage/common/storage-network-security.md).
 
 ### Azure Storage firewall
 

articles/machine-learning/how-to-enable-studio-virtual-network.md

@@ -67,12 +67,6 @@ In this article, you learn how to:
 
 ### Azure Storage Account
 
-* There's a known issue where the default file store does not automatically create the `azureml-filestore` folder, which is required to submit AutoML experiments. This problem occurs when users bring an existing file store to set as the default file store during workspace creation.
-
-    To avoid this issue, you have two options: 1) Use the default file store, which is automatically created for you doing workspace creation. 2) To bring your own file store, make sure the file store is outside of the VNet during workspace creation. After the workspace is created, add the storage account to the virtual network.
-
-    To resolve this issue, remove the file store account from the virtual network then add it back to the virtual network.
-
 * When the storage account is in the VNet, there are extra validation requirements when using studio:
 
     * If the storage account uses a __service endpoint__, the workspace private endpoint and storage service endpoint must be in the same subnet of the VNet.