title | description | services | documentationcenter | author | manager | editor | tags | ms.service | ms.devlang | ms.topic | ms.tgt_pltfrm | ms.workload | ms.date | ms.author |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
42 characters followed by | Microsoft Docs |
Displayed in search engines under the title. You have more room here, use more keywords and a more descriptive explanation than the title |
service-name |
dev-center-name |
GitHub-alias-of-only-one-author |
manager-alias |
top-support-issue |
required |
may be required |
article |
may be required |
required |
mm/dd/yyyy |
Your MSFT alias or your full email address;semicolon separates two or more |
Use 2-3 secondary keywords in the description.
Select one of the following disclaimers depending on your scenario. If your article is deployment model agnostic, ignore this.
[!INCLUDE learn-about-deployment-models] classic deployment model.
[!INCLUDE learn-about-deployment-models]
[Opening paragraph]
- Briefly describe the specific issue(s) that this article will help troubleshoot, and the common root cause(s).
- The opening paragraph is a good place to use different keywords from those in the title, but make sure to not make it very wordy. The sentences should flow well and be easy to understand.
- Exceptions (optional) - List the relevant scenarios that are not covered in this article. For example, ” Linux/OSS scenarios aren't covered in this article”.
These {errors}|{Issues} occur because {a very general reason}.
Here is an example of an opening paragraph.
When you try to connect to Azure SQL Database, the common connection errors you encounter are:
- The login failed for the user. The password change failed.
- Password validation failed.
- Failed to authorize access to the specified subscription.
These errors occur because you don’t have permission to access the data source.
If it is an article on the billing topic, include the following note (the note below is slightly different than the one at the bottom of this article):
Note
If you need more help at any point in this article, please contact support to get your issue resolved quickly.
If it is NOT a billing article, include the following reference: [!INCLUDE support-disclaimer]
- Use this section when the guidance applies across the board.
- Don’t go into details. Keep it high level to serve as a guidance.
Here is an example of a troubleshooting guidance.
In general, as long as the error does not indicate "the requested VM size is not supported", you can always retry at a later time, as enough resource may have been freed up in the cluster to accommodate your request. If the problem is the requested VM size is not supported, try a different VM size; otherwise, the only option is to remove the pinning constraint.
List the solutions in the order of usability and simplicity, meaning the simplest, the most effective and useful solution should go first.
Select one of the versions that apply to your situation.
Version 1: Your article is deployment model agnostic | Version 2: Steps for Resource Manager and Classic are largely the same | Version 3: Steps for Resource Manager and Classic are mostly different. In this case, use the Simple Selectors technique in GitHub. Note: VM articles for ARM are exceptions and should not use the ARM/Classic selector. |
---|---|---|
[Error 1][Cause details](the simplest and most effective)
|
[Error 2][Cause details](the simplest and most effective)
|
Include this section if there are 1 -3 concrete, highly relevant next steps the user should take. Delete if there are no next steps. This is not a place for a list of links. If you include links to next steps, make sure to include text to explain why the next steps are relevant/ important.
If it is an article on the billing topic, include the following note (the note below is slightly different than the one at the beginning of this article):
Note
If you still have further questions, please contact support to get your issue resolved quickly.