Merge pull request #220 from ee61re/master

various documentation updates

ADMXImport.md

@@ -12,7 +12,7 @@ Microsoft links:
 
 ## ADMX Import
 
-The **ADMX Import** tool is used for configuring 3rd party applications e.g. Chrome, Google Update etc., These ADMX files are available from the software vendor. An ADMX can be loaded in the tool and all settings can be configured using a similar UI as GPMC. When the ADMX is loaded, the script will look for an ADML file that is either in the same directory or in the en-US subdirectory. An ADML file can also be loaded manually, if another language should be used in the UI.
+The **ADMX Import** tool is used for configuring 3rd party applications e.g. Chrome, Google Update etc. These ADMX files are available from the software vendor. An ADMX can be loaded in the tool and all settings can be configured using a similar UI as GPMC. When the ADMX is loaded, the script will look for an ADML file that is either in the same directory or in the en-US subdirectory. An ADML file can also be loaded manually, if another language should be used in the UI.
 
 <img src="https://raw.githubusercontent.com/Micke-K/IntuneManagement/master/ADMXExample.png" height="50%" width="50%"/>
 
@@ -24,11 +24,11 @@ A policy setting can either be edited via double-clicking an item or right-click
 
 The *Intune OMA-URI name* property specifies the name of the OMA-URI row in the Custom Profile. This is optional and if it is not specified, the script will use the name of the policy.
 
-A policy must be set to Enabled before any changes can be made. The *Policy* tab will list all possible settings for the policy. This could be a dropdown box, text box, check box, numeric up-down box etc. The script creates the controls based on the presentation settings in the ADML file. An ADML is not mandatory but the controls and the UI could cause unpredictive results. Always use the associated ADML for correctly generated controls.
+A policy must be set to Enabled before any changes can be made. The *Policy* tab will list all possible settings for the policy. This could be a dropdown box, text box, check box, numeric up-down box etc. The script creates the controls based on the presentation settings in the ADML file. An ADML is not mandatory but the controls and the UI could cause unpredictable results. Always use the associated ADML for correctly generated controls.
 
 <img src="https://raw.githubusercontent.com/Micke-K/IntuneManagement/master/ADMXSettingExampleOMAURI.png" height="50%" width="50%"/>
 
-The *OMA-URI Settings* tab contains the configured settings. This is the string that will be added to the enabled policy. This can be manually configure in case there is something that is not supported by the script. Do **NOT** add <enabled /> or <disabled /> to this text box. The script will add that automatically.  If *Manual configuration* is checked, the script will upload the text as it is specified, including additional manual changes. If it is not checked, the script will generate the text when importing the profile. If manual configuration is added and then checkbox is cleared, those changes will be lost during the upload.
+The *OMA-URI Settings* tab contains the configured settings. This is the string that will be added to the enabled policy. This can be manually configured in case there is something that is not supported by the script. Do **NOT** add <enabled /> or <disabled /> to this text box. The script will add that automatically.  If *Manual configuration* is checked, the script will upload the text as it is specified, including additional manual changes. If it is not checked, the script will generate the text when importing the profile. If manual configuration is added and then checkbox is cleared, those changes will be lost during the upload.
 
 The *XML Definition* tab contains the XML node for the ADMX policy. This is used for reference in case manual configuration is required.
 
@@ -211,4 +211,4 @@ The following events can be used for troubleshooting:
 * Values outside Software\Policies will **NOT** be deleted when the policy is removed.
 * The tool supports all ADMX attributes specified in the schema but it looks like some functionalities are not supported by Windows or the Policy CSP e.g. the *soft* attribute should be set to true to avoid overwriting an existing value but all values were overwritten during the tests, even if the soft attribute was set. 
 * QWORD is not supported. The ADMX schema definition includes longDecimal which would create QWORD values but this is not supported in the Policy CSP. It will generate a Catastrophic Failure event in the Event Log. 
-* No support for enabledList/disabledList. This might be added in the future since this could make it very easy to create mapped drives via ADMX ingestion. 
+* No support for enabledList/disabledList. This might be added in the future since this could make it very easy to create mapped drives via ADMX ingestion. 

Documentation.md

@@ -2,7 +2,7 @@
 
 The script can document most of the profiles and policies in Intune. The output can either be CSV or Word. Documenting to Word can either be to an existing Word template or empty document. There are many options for the documentation e.g. Language, Header styles, Table styles, managing not configured items etc.  
 
-The idea behind the documentation method in the script is to output the information as close to the Endpoint Manager portal as possible. Some of the objects has a different property name or value in the Summary text vs Edit mode in the portal. The documentation will then use the Edit mode information when possible. Some policies and profiles might have a slightly different order that the portal.
+The idea behind the documentation method in the script is to output the information as close to the Endpoint Manager portal as possible. Some of the objects has a different property name or value in the Summary text vs Edit mode in the portal. The documentation will then use the Edit mode information when possible. Some policies and profiles might have a slightly different order than the portal.
 
 The objects can be documented in three ways:
 
@@ -28,7 +28,7 @@ Please read the [Deep Dive](#deep-dive) section below for a detailed description
 
 The script can document the objects in any language supported by Intune. 
 
-Note that some profiles and properties does not have language support. These will be documented in English.
+Note that some profiles and properties do not have language support. These will be documented in English.
 
 **Known Issues**
 
@@ -36,7 +36,7 @@ This is the first version of the documentation support.
 
 * There are over 100 different object types. Not all are supported and not all supported object types are tested and verified. 
 
-* Property based profiles might be missing some properties. Some properties in the translation files are generated at runtime. Support for these properties are added in the custom documentation provider
+* Property based profiles might be missing some properties. Some properties in the translation files are generated at runtime. Support for these properties are added in the custom documentation provider.
 
 * Some complex type properties are not translated in this version e.g. the screen layout of apps on the iPhone. 
 
@@ -52,7 +52,7 @@ This is the first version of the documentation support.
 
 * Some Endpoint Security polices are NOT deviceManagementIntent objects. They are actually Settings Catalog objects and they will be listed with the Settings Catalog items e.g. *Antivirus - Windows 10 and Windows Server (ConfigMgr)* policies
 
-* Some Endpoint Security/Settings Catalog items is not translated based on Graph API in the portal e.g. *Antivirus - Windows 10 and Windows Server (ConfigMgr)* policies.  These will be documented based on Graph API information which might be different compared to the portal
+* Some Endpoint Security/Settings Catalog items are not translated based on Graph API in the portal e.g. *Antivirus - Windows 10 and Windows Server (ConfigMgr)* policies.  These will be documented based on Graph API information which might be different compared to the portal
 
 * Markdown is currently in experimental state. The script can document to an MD file created in the Documents folder but this can be to large in environments with many objects. The script will create HTML tables to support code blocks and column span. The MD View must support HTML tables to display the document. The *Markdown Viewer* extension in Chrome was used during testing.
 
@@ -93,7 +93,7 @@ Property based objects are very complex to document. These objects can be docume
 * PowerShell function
 * Or a combination of PowerShell and manually created json files 
 
-Json files for translating property objects to documentation is located in the Documentation\ObjectInfo folder. All files that start with a # is manually created. These can either be based on the object type (@OData.Type) or the Object Type Id (specified in the EndpointManager.psm1 file). Files that does not start with a # are automatically generated and the `ObjectCategories.json` file contains the mapping between the Intune object and associated json files. One object type can be associated with multiple files. Each file represents one category of the object.
+Json files for translating property objects to documentation is located in the Documentation\ObjectInfo folder. All files that start with a # are manually created. These can either be based on the object type (@OData.Type) or the Object Type Id (specified in the EndpointManager.psm1 file). Files that does not start with a # are automatically generated and the `ObjectCategories.json` file contains the mapping between the Intune object and associated json files. One object type can be associated with multiple files. Each file represents one category of the object.
 
 The generated files sometimes requires additional manually created properties. These could be properties in the UI that has a Yes/No, Enabled/Not Configured etc. trigger associated with a specific value. These properties must be manually added to the object before the documentation. The `DocumentationCustom.psm1` file takes care of this. This file is also used for overriding the documentation of specific values and other custom required processing.    
 
@@ -103,7 +103,7 @@ The `DocumentationCustom.psm1` file also takes care of custom documentation for
 
 **Language Support**
 
-The Settings based objects get their language strings from Graph APIs with a few exemptions.
+The Settings based objects get their language strings from Graph APIs with a few exceptions.
 
 The property based objects uses static language files. Each language file is generated based on multiple language files. Not all the language information is included in these files to reduce the output size. This could reduce the possibility to create custom documentation with multi language support.
 
@@ -111,7 +111,7 @@ These files will have to be re-generated when new functionality is released in I
 
 **Scripts for Generated Files**
 
-The scripts that automatically generates language files, translation files, object info etc. are not included in the release. These scripts are currently not in a state that they can be released. The best would be if Microsoft released all the required information in Graph. A deep dive into graph suggests that it might be possible in the future since some information about the generated files are there but with some properties missing or language text missing. The information can't be accessed unless an API is called that gets the definition for all the profiles at the same time (the file is over 100MB). 
+The scripts that automatically generate language files, translation files, object info etc. are not included in the release. These scripts are currently not in a state that they can be released. The best would be if Microsoft released all the required information in Graph. A deep dive into graph suggests that it might be possible in the future since some information about the generated files are there but with some properties missing or language text missing. The information can't be accessed unless an API is called that gets the definition for all the profiles at the same time (the file is over 100MB). 
 
 ## Extending The Documentation
 
@@ -132,9 +132,9 @@ The priority order for object documentation is:
 
 **Documentation Provider**
 
-The documentation provider takes care of collecting all the information about the object. The `DocumentationCustom.psm1` file is an example of this. This file has examples of custom translation of properties for json files and examples of custom translation of objects via a PowerShell functions.
+The documentation provider takes care of collecting all the information about the object. The `DocumentationCustom.psm1` file is an example of this. This file has examples of custom translation of properties for json files and examples of custom translation of objects via PowerShell functions.
 
-Documentation providers has a Priority property. This defines in what order the providers will be triggered. The provider with the lowest priority number will be executed first. The included custom documentation provider has a priority number of 1000. The information gathering of the provider can be overridden by creating a custom documentation provider with a lower priority number.
+Documentation providers have a Priority property. This defines in what order the providers will be triggered. The provider with the lowest priority number will be executed first. The included custom documentation provider has a priority number of 1000. The information gathering of the provider can be overridden by creating a custom documentation provider with a lower priority number.
 
 **Documentation Output Provider**
 

MSALInfo.md

@@ -29,7 +29,7 @@ The MSAL authentication will create a token that is used when calling APIs in Mi
 
 The token expire after 1 hour. The script will do a "login" every time it calls an API. MSAL will manage the refresh of the token and only refresh it when it is about to expire or after it has expired. If the token needs to be refreshed e.g. the user was added to a new role, a forced refresh can be triggered in the Profile Info popup.  
 
-The Token info will show information like role memberships, expiry time, scope etc. There are three toke information available:
+The Token info will show information like role memberships, expiry time, scope etc. There are three tokens with information available:
 
 * MSAL Token - Token created when authenticating with MSAL. Contains the Access and ID tokes
 * Access token - Token contains permissions information and used when calling Microsoft Graph APIs 
@@ -46,4 +46,4 @@ Support for switching to other tenants can be enabled in Settings. This can be u
 * Reduce login time - Getting the list of accessible tenants takes a few seconds extra 
 * Reduce prompts - There is no API in Microsoft Graph that returns a list of tenants the current user has access to. Instead, a Azure management API is used. This will require permissions to Azure management which might cause an additional prompt for Consent when logging in.
 
-**Note:** This is only used when a user has access to multiple tenants. Users from other tenants can always be used without enabling the 'Get Tenant List' setting.
+**Note:** This is only used when a user has access to multiple tenants. Users from other tenants can always be used without enabling the 'Get Tenant List' setting.

README.md

@@ -6,11 +6,11 @@
   </a>
 </p>
 
-These PowerShell scripts are using Microsoft Authentication Library (MSAL), Microsoft Graph APIs and Azure Management APIs to manage objects in Intune and Azure. The scripts has a simple WPF UI and it supports operations like Export, Import, Copy, Download, Compare etc.
+These PowerShell scripts are using Microsoft Authentication Library (MSAL), Microsoft Graph APIs and Azure Management APIs to manage objects in Intune and Azure. The scripts have a simple WPF UI and it supports operations like Export, Import, Copy, Download, Compare etc.
 
 This makes it easy to backup or clone a complete Intune environment. The scripts can export and import objects including assignments and support import/export between tenants. The scripts will create a migration table during export and use that for importing assignments in other environments. It will create missing groups in the target environment during import. Group information like name, description and type will be imported based on the exported group e.g. dynamic groups are supported. There will be one json file for each group in the export folder.
 
-The script also support dependencies e.g. an App Protection is depending on an App, Policy Sets are depending on Compliance Policies, objects has Scope Tags etc. Dependency support requires exported json files and that the dependency objects are imported in the environment. The script uses the exported json files to get the Id and name's of the exported object and uses that information and updates Id's before import an object from a json file. The Bulk Import form shows the import order of the objects. The objects with the lowest order number will be imported first.
+The script also support dependencies e.g. an App Protection is depending on an App, Policy Sets are depending on Compliance Policies, objects has Scope Tags etc. Dependency support requires exported json files and that the dependency objects are imported in the environment. The script uses the exported json files to get the Id and names of the exported object and uses that information and updates Id's before import an object from a json file. The Bulk Import form shows the import order of the objects. The objects with the lowest order number will be imported first.
 
 <p align="center">
   <img src="https://raw.githubusercontent.com/Micke-K/IntuneManagement/master/IntuneManagement.PNG" height="80%" width="80%"/>
@@ -29,7 +29,7 @@ Before starting the app:
 
 Before logging on:
 
-* The app will use the Intune PowerShell Azure Enterprise Application by default and only use the permissions granted to that appliction. Disable **Use Default Permissions** in Settings to request additional permissions. The will cause a consent prompt if one or more permissions are missing for the app.
+* The app will use the Intune PowerShell Azure Enterprise Application by default and only use the permissions granted to that appliction. Disable **Use Default Permissions** in Settings to request additional permissions. This will cause a consent prompt if one or more permissions are missing for the app.
   **Note:** If the app has not been approved for the organization, a consent prompt will be displayed.  
 * Enable **Get Tenant List** in Settings if accessing multiple environments with the same account e.g. a guest account in other tenants. This might cause a Consent prompt
 
@@ -46,7 +46,7 @@ Silent batch job is supported by the following features:
 
 The Silent Batch Job feature requires an Azure App to be configured with a secret or a certificate. The app must also be delegated with the required permissions to Graph objects used by the tool.
 
-The silent feature uses an exported json file with settings for the specified operation. This file can be generated in the Bulk Export/Import forms. Required settings for the silent job is configured in the form and then exported to a file. The path to the file is then passed on the command line. The file can be used for multiple environments if the **Add company name to the path** option is selected. Note that this requires that the appmust have at least read permission on the Organizations API.
+The silent feature uses an exported json file with settings for the specified operation. This file can be generated in the Bulk Export/Import forms. Required settings for the silent job is configured in the form and then exported to a file. The path to the file is then passed on the command line. The file can be used for multiple environments if the **Add company name to the path** option is selected. Note that this requires that the app must have at least read permission on the Organizations API.
 
 The following variables can be used in the path and filename:
 
@@ -96,7 +96,7 @@ The script can import the exported json files in multiple ways.
   
 * **Update (Preview):** This will update the existing object.
   
-  The update APIs does not support all the properties that the import API sdoes and object types behaves differently during update e.g. Settings for **Endpoint Security** objects will not be cleared. There is no API for removing settings, only adding. If a setting does not exist in the import file, the existing setting will be set to *Not Configured*. **Settings Catalog** replaces the whole settings property during update. 
+  The update APIs do not support all the properties that the import APIs do and object types behaves differently during update e.g. Settings for **Endpoint Security** objects will not be cleared. There is no API for removing settings, only adding. If a setting does not exist in the import file, the existing setting will be set to *Not Configured*. **Settings Catalog** replaces the whole settings property during update. 
   
   This has been tested with all supported object types *except* Import Scripts (Shell), Android OEM Config and Apple Enrollment Types.
   
@@ -163,7 +163,7 @@ Additional Intune Tools is included in the script.
 
 * Intune Assignments
   * Quickly gather all assignments from an export
-  * Easily identify all profiles/polices a group is assigned to
+  * Easily identify all profiles/policies a group is assigned to
   * Export as CSV to analyse in Excel 
 
 See [ADMX Import](ADMXImport.md) for more information about the ADMX tools
@@ -172,9 +172,9 @@ See [ADMX Import](ADMXImport.md) for more information about the ADMX tools
 
 Custom columns is supported. The script will by default add id, displayName and description with exception for some object types. These are configured in the EndpointManager.ps1 and  EndpointManagerInfo.psm1 files.
 
-Custom columns can be added for each Object Type in the detealed view of an Object. 
+Custom columns can be added for each Object Type in the detailed view of an Object. 
 
-Custom Columuns settings are stored in the regitry, in HKCU\SOFTWARE\CloudAPIPowerShellManagement\EndpointManager\ObjectColumns\\*ObjectType*.
+Custom Columns settings are stored in the regitry, in HKCU\SOFTWARE\CloudAPIPowerShellManagement\EndpointManager\ObjectColumns\\*ObjectType*.
 
 The *ObjectType* value represents the ViewItem ID specified in the EndpointManager.ps1 and EndpointManagerInfo.psm1 files. This is also the same as the parent folder when items are exported.
 
@@ -324,7 +324,7 @@ Logout will only clear the token from cache and not from the browser e.g. if log
 ~~Referenced settings will NOT be imported/copied. There is no value stored in a property on the object for these settings. Example: A VPN profile has certificates as referenced properties. The certificates must be added manually after import/copy.~~
 Issue fixed in 3.5.0 
 
-Terms of Use requires that the pdf file is available. This must be manually coped to either the Export folder for Terms of Use or to the Intune Application folder specified in Settings. It is currently not possible to export the pdf file with Graph API. 
+Terms of Use requires that the pdf file is available. This must be manually copied to either the Export folder for Terms of Use or to the Intune Application folder specified in Settings. It is currently not possible to export the pdf file with Graph API. 
 
 The ADMX/ADML files must be manually copied to either the Export folder for Administrative Templates or to the Intune Application folder specified in Settings. It is currently not possible to export the pdf file with Graph API.