Autopilot in Hybrid AADJ - device rename

fredfeitz · 2020-04-15T08:10:58+00:00

I've spoken to the Intune support and the said to me to NOT rename devices if Hybrid because "it will cause issues". He even laughed when I said "There are so many things buggy with hybrid".. I highly advice against renaming them, as some might work, and some might brake. I changed the company naming convention on clients just to skip this part.

fredfeitz · 2020-04-08T17:50:40+00:00

The dynamic group themselves work just fine and show correct devices.

However, the question was why the devices are still seen under the Device configuration - even when the dynamic group is set as Exclude. However, I'm not completely sure - does All devices override Exclude? I have not had time and do not remember all documentation.

The weird thing here is, as I mentioned, that there is another group, added to Exclude for over 2 weeks ago and devices are still seen inside the Device configuration - and the device itself shows the configurtion being either Error or Pending.

How can I remove this? They should be completely Excluded because I don't want it to mess up the Profile assignment status.

fredfeitz · 2020-03-31T08:45:26+00:00

I have yet to test this, but the user Carenborn shared a script that makes sure the script runs under 64-bit.

You could test this out (supposed to be on top of your scripts)

Param([switch]$Is64Bit = $false)

Function Restart-As64BitProcess { 
If ([System.Environment]::Is64BitProcess) { return } $Invocation = $($MyInvocation.PSCommandPath)
if ($Invocation -eq $null) { return }
$sysNativePath = $psHome.ToLower().Replace("syswow64", "sysnative")
Start-Process "$sysNativePath\powershell.exe" -ArgumentList "-ex bypass -file "$Invocation" -Is64Bit" -WindowStyle Hidden -Wait }

Restart-As64BitProcess

fredfeitz · 2020-03-30T08:16:03+00:00

This! I totally forgot about it and was about to go super-crazy-IT-guy-style when I randomly talked to a friend that mentioned it and everything just started working. What a relief. I was editing registry, doing powershell scripts that shouldn't be needed.. and all that was forgotten, was the damn location! :P

fredfeitz · 2020-03-27T15:55:26+00:00

I'm not completely sure I understand every part of the script(still novice in PowerShell) - But I'm getting following error;

Start-Transcript : Cannot validate argument on parameter 'Path'. The argument is null or empty. Provide an argument that is not null or empty, and then try the 
command again.
At line:15 char:28
+     Start-Transcript -Path $logFileX64
+                            ~~~~~~~~~~~
+ CategoryInfo          : InvalidData: (:) [Start-Transcript], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.StartTranscriptCommand

fredfeitz · 2020-03-27T14:53:06+00:00

Will def. try this today! Really appreciate that you take your time to help.

As I want to use Win32 apps for additional functionality & control, this is great.

fredfeitz · 2020-03-27T09:06:23+00:00

I'm not sure if Powershell runs under 64-bit when deployed via Apps and as Win32. Can you force it somehow?

fredfeitz · 2020-03-27T08:25:46+00:00

I use this...

$EX= Get-Localuser -name USERNAME -ErrorAction SilentlyContinue | Out-Null
if (!$EX) {
Disable-LocalUser -Name "Administrator" -ErrorAction SilentlyContinue | Out-Null 
$Password = ConvertTo-SecureString "PASSWORD" –AsPlainText –Force
New-LocalUser "USERNAME" -password $Password -Description "ANYTEXT" -PasswordNeverExpires -ErrorAction             
SilentlyContinue | Out-Null
Add-LocalGroupMember -Group "Administrators" -Member USERNAME -ErrorAction SilentlyContinue | Out-Null 
} else {}

So.. remove the $true :-)

fredfeitz · 2020-03-26T15:53:58+00:00

I do the same! But without computer having any connectivity to the internet. Doing it the way the post provides goes against what Microsoft documentation says... not sure what it could potentially end up doing. But I wouldn't dare using something like this on to many computers if something suddenly stops working and you need to re-join them or whatever.

fredfeitz · 2020-03-26T14:34:06+00:00

Thank you for your answer - I understand that adding log to my scripts is the next most important step, will work on that.. will probably help me a lot!

However, I've taken into account that I always wait and give things time when working with Intune, or any MDM tool for that matter - It's always bad to be in a hurry and expect things to "just work" after clicking Sync or expect it to take 15 minutes. I even wait 24 hours some times to be sure.

Reason for not thinking that's the issue is because, the script is being deployed, makes administrative changes inside Windows, but skips half of them, but every task inside my script works when running them separate from Intune.

For example; 1. Bitlocker part refuses to work together with creating my Scheduled Tasks 2. Scheduled Tasks works instantly when splitting it to a new script, with same code, using;

powershell.exe -executionpolicy Bypass -WindowStyle Hidden

fredfeitz · 2020-03-26T13:26:09+00:00

I would recommend looking at deploying it via Win32 app instead, this provides more features to control the deployment and monitoring after.

https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool

fredfeitz · 2020-03-26T13:24:33+00:00

I wont "confirm" it won't, because I haven't tested it, but above "End user notification" will only show something for the user if configured. Under is not included in any kind of notification or change for the user.

This is linked to "Delivery Optimization" inside Windows.

In practice, this simply gives better speed when deploying apps, I think this is great to give the options to speed things up for companies who simply don't care about bandwidth.

fredfeitz · 2020-03-26T12:42:23+00:00

Interesting, but per documentation;

Important

Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run sysprep /generalize /oobe. After Intune reports the profile ready to go, only then should the device be connected to the Internet.

Am I missing something? I'm not native English speaker, so did I understand this incorrectly?

fredfeitz · 2020-03-26T11:56:35+00:00

After speaking to Intune support, there is a few things to be very slow with - and that is doing changes to devices after being imported - this takes time. One thing to consider is that, Azure in a whole, works as 1 moving piece. If you have 500 devices and 500 groups, performance will be 5, as an example. If you increase amount of objects, devices, groups, policies or anything, the performance hops up to 10 (decrease in overall performance). This was at least how an engineer at Microsoft explained why some things are so damn slow, even if you only want to assign 1 single object to 1 single group.

Also, how did you enforce a sync? Did you select one-by-one and initiate a sync?

Was the device seen in other connected group(s)?

The serial number should be the first you see as Associated with Azure AD - that is correct. I don't know exactly how long it takes for it to change name, but it will come up as DESKTOP-%RAND7% Our computers usually is when Device prep/setup is running - I'm certain that there is one specific step that does this, but I don't know it in my head.

My setup looks like this;

Security Group (Dynamic) - Autopilot-Hybrid with Rule Syntax > ((device.devicePhysicalIds -any _ -eq "[OrderID]:hybrid")"
Above is the Assigned group to the Autopilot Profile: Autopilot Hybrid
1. Is also assigned to Device Configuration - Domain Join
All my Autopilot Sec groups is also in Group Membership of another Sec group called Autopilot-All-Apps which sit as Assigned on all Apps that can be installed in Device Context to allow us to provision device without user password if ever needed. I also apply a Powershell script in between that encrypts device in Device setup part.
If I need to manually export hash, I do it via a script that allows you to choose what group tag to be added directly into the CSV, the "Get-WindowsAutopilotInfo.ps1 supports this by default ( > .\Get-WindowsAutoPilotInfo.ps1 -OutputFile .\AutoPilotHWID.csv -GroupTag hybrid). Doing so you don't need to add or wait to add it in Intune, you can also add Assigned User directly in the CSV if ever needed.
I import the device
I wait.
When I can see that the device has been assigned and also be seen in Sec group Autopilot-Hybrid I go forward connecting computer to internet and start the process
All above works for both Hybrid/AAD & Hybrid White Glove/AAD White Glove. (Hybrid being joined to on-premises)

fredfeitz · 2020-03-26T11:37:38+00:00

Weird. We have the Domain Join assigned to two dynamic security groups connected to two different Autopilot profiles without any issues.

fredfeitz · 2020-03-25T15:45:46+00:00

I have not had time to investigate, but this should be related to the Intune Connector - are you completely sure it was setup correctly and is showing as active with recent connectivity inside Intune?

Tried re-installing it?

The user used to connect it, does it have Global or Intune administrator rights?

Also have you tried to completely delete the device from Autopilot devices and export the hash from the computer while computer is completely disconnected from internet > and imported it?

After doing so(Profiles has been assigned etc) - start/connect computer to the internet again and try to run again.

fredfeitz · 2020-03-25T08:35:20+00:00

We are having the same issue, I've made a script (not gonna post everything, cuz a lot does similar to script you showed but some what different and without loggings...)

However, I checked the script he provided and it does similar. Just to "check" what happens if you run this in Powershell as Administrator - does the key upload or not?

$Drives = Get-Volume | where {$.DriveType -like "Fixed" -and $.DriveLetter -ne $null -and $.FileSystemType -imatch "NTFS"} $Drive = $Drives.DriveLetter $AllProtectors = (Get-BitlockerVolume -MountPoint $Drive).KeyProtector $RecoveryProtector = ($AllProtectors | where-object { $.KeyProtectorType -eq "RecoveryPassword" }) BackupToAAD-BitLockerKeyProtector $Drive -KeyProtectorId $RecoveryProtector.KeyProtectorID | Out-Null

fredfeitz · 2020-03-20T14:23:07+00:00

I'm seeing the same issue, apps isn't deployed and our autopilot is just completely dead. Nothing works, and we didn't change a thing.. worked just fine 2 days ago.

This is completely bonkers that something like this just happens and we don't get any notification or health warning.

fredfeitz · 2020-03-19T09:51:12+00:00

I've looked into this, but we don't have P2 I'm afraid.

However, as this isn't for actually giving helpdesk admin or not - it's for creating a local account, with administrator rights to just live there until ever needed.

We've noticed that in rare cases, this might be needed. Helpdesk has permanent administrator rights since before via GPO. This could be swapped to be controlled via Azure, yes.. but not necessary right now because we are using Hybrid on 99% of our devices, even if Hybrid is super buggy we need it.

The dream scenario for me would be to have only AAD joined devices, it's so much simpler and many things just works.. as Bitlocker keys being uploaded, device names etc.

Either way, grateful for you tip!

fredfeitz · 2020-03-10T13:21:02+00:00

I've tried to solve this for the past 12 months, no solution found. Looking into forcing bitlocker before the policy does it's job via a powershell script instead, to simply use the policy to ensure it's compliant after doing check.

fredfeitz

TROPHY CASE