mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-14 22:37:22 +00:00
Merge pull request #2183 from MicrosoftDocs/repo_sync_working_branch
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
commit
9da3bb9642
@ -42,6 +42,46 @@ For troubleshooting, key activities to perform are:
|
|||||||
- Azure AD join issues. Was the device able to join Azure Active Directory?
|
- Azure AD join issues. Was the device able to join Azure Active Directory?
|
||||||
- MDM enrollment issues. Was the device able to enroll in Microsoft Intune (or an equivalent MDM service)?
|
- MDM enrollment issues. Was the device able to enroll in Microsoft Intune (or an equivalent MDM service)?
|
||||||
|
|
||||||
|
## Troubleshooting Autopilot Device Import
|
||||||
|
|
||||||
|
### Clicking Import after selecting CSV does nothing, '400' error appears in network trace with error body **"Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'"**
|
||||||
|
|
||||||
|
This error points to the device hash being incorrectly formatted. This could be caused by anything that corrupts the collected hash, but one possibility is that the hash itself, even if completely valid, fails to be decoded.
|
||||||
|
|
||||||
|
The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Autopilot expects padded Base64. In most cases, it seems the payload lines up to not require padding, so the process works, but sometimes it doesn't line up cleanly and padding is necessary. This is when you get the error above. Powershell's Base64 decoder also expects padded Base64, so we can use that to validate that the hash is properly padded.
|
||||||
|
|
||||||
|
The "A" characters at the end of the hash are effectively empty data - Each character in Base64 is 6 bits, A in Base64 is 6 bits equal to 0. Deleting or adding "A"s at the end doesn't change the actual payload data.
|
||||||
|
|
||||||
|
To fix this, we'll need to modify the hash, then test the new value, until powershell succeeds in decoding the hash. The result is mostly illegible, this is fine - we're just looking for it to not throw the error "Invalid length for a Base-64 char array or string".
|
||||||
|
|
||||||
|
To test the base64, you can use the following:
|
||||||
|
```powershell
|
||||||
|
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH"))
|
||||||
|
```
|
||||||
|
|
||||||
|
So, as an example (this is not a device hash, but it's misaligned unpadded Base64 so it's good for testing):
|
||||||
|
```powershell
|
||||||
|
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA"))
|
||||||
|
```
|
||||||
|
|
||||||
|
Now for the padding rules. The padding character is "=". The padding character can only be at the end of the hash, and there can only be a maximum of 2 padding characters. Here's the basic logic.
|
||||||
|
|
||||||
|
- Does decoding the hash fail?
|
||||||
|
- Yes: Are the last two characters "="?
|
||||||
|
- Yes: Replace both "=" with a single "A" character, then try again
|
||||||
|
- No: Add another "=" character at the end, then try again
|
||||||
|
- No: That hash is valid
|
||||||
|
|
||||||
|
Looping the logic above on the previous example hash, we get the following permutations:
|
||||||
|
- Q29udG9zbwAAA
|
||||||
|
- Q29udG9zbwAAA=
|
||||||
|
- Q29udG9zbwAAA==
|
||||||
|
- Q29udG9zbwAAAA
|
||||||
|
- Q29udG9zbwAAAA=
|
||||||
|
- **Q29udG9zbwAAAA==** (This one has valid padding)
|
||||||
|
|
||||||
|
Replace the collected hash with this new padded hash then try to import again.
|
||||||
|
|
||||||
## Troubleshooting Autopilot OOBE issues
|
## Troubleshooting Autopilot OOBE issues
|
||||||
|
|
||||||
If the expected Autopilot behavior does not occur during the out-of-box experience (OOBE), it is useful to see whether the device received an Autopilot profile and what settings that profile contained. Depending on the Windows 10 release, there are different mechanisms available to do that.
|
If the expected Autopilot behavior does not occur during the out-of-box experience (OOBE), it is useful to see whether the device received an Autopilot profile and what settings that profile contained. Depending on the Windows 10 release, there are different mechanisms available to do that.
|
||||||
|
@ -92,6 +92,9 @@ The following table lists the services and their associated URLs that your netwo
|
|||||||
| United Kingdom | unitedkingdom.x.cp.wd.microsoft.com <br/> uk-v20.events.data.microsoft.com |
|
| United Kingdom | unitedkingdom.x.cp.wd.microsoft.com <br/> uk-v20.events.data.microsoft.com |
|
||||||
| United States | unitedstates.x.cp.wd.microsoft.com <br/> us-v20.events.data.microsoft.com |
|
| United States | unitedstates.x.cp.wd.microsoft.com <br/> us-v20.events.data.microsoft.com |
|
||||||
|
|
||||||
|
> [!NOTE]
|
||||||
|
> For a more specific URL list, see [Configure proxy and internet connectivity settings](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet#enable-access-to-microsoft-defender-atp-service-urls-in-the-proxy-server)
|
||||||
|
|
||||||
Microsoft Defender ATP can discover a proxy server by using the following discovery methods:
|
Microsoft Defender ATP can discover a proxy server by using the following discovery methods:
|
||||||
- Transparent proxy
|
- Transparent proxy
|
||||||
- Manual static proxy configuration
|
- Manual static proxy configuration
|
||||||
|
Loading…
x
Reference in New Issue
Block a user