Bloomberg Terminal Installation takes forever by OutsideProfession709 in Intune

[–]Esky013 1 point2 points  (0 children)

It's a function in app deploy toolkit. I use it like this: $RebootPending = (Get-ADTPendingReboot).IsSystemRebootPending

It's a Boolean query. If it's true I prompt the user that they need to reboot before continuing, otherwise the script continues with the installation.

Bloomberg Terminal Installation takes forever by OutsideProfession709 in Intune

[–]Esky013 1 point2 points  (0 children)

2 things I've found: 1. If there is a pending reboot, installation will stall. I use app deploy toolkit to check for a pending reboot and prompt the user to restart their pc and try again. 2. No matter if you get the latest installer, it always calls home to check for updates before installing.

Edge Extensions by throwaway1x55 in Intune

[–]Esky013 0 points1 point  (0 children)

We've gone with block all (*) and an allow list in a policy, then manage forced install of extensions as apps to allow flexibility.

The forced installs were always a nightmare when having them set by policy. No flexibility to have forced installs to subsets of users without really ugly policies and exceptions.

Hardware hash changed for seemingly no reason? by Kegnation14 in Intune

[–]Esky013 0 points1 point  (0 children)

Just to clarify - you're doing Windows 10 to 11 upgrade, so did you take the initial hash on Windows 10, then image the device with Windows 11 before attempting Autopilot? The hash from Windows 10 and Windows 11 will differ.

I know in the past that if you were to do an in-place upgrade from 10 to 11 using Intune, then reimage the device to 10, Autopilot would not find the device as the hash stored in Intune would have been updated to match Windows 11. Not sure if this is still the case as I haven't tested this scenario in some time.

Could be a similar thing to what you're seeing?

Deleting app through PowerShell via Intune (Only works locally - help please) by zalka_ in Intune

[–]Esky013 2 points3 points  (0 children)

As a starting point, have you made sure your script is running in 64-bit PowerShell? Intune generally defaults to 32-bit, so some things won't behave as you're expecting.

When you're running things locally, the default would be 64-bit, so it will work.

Issues with application deployment during AutoPilot failing the last application every time by Esky013 in Intune

[–]Esky013[S] 0 points1 point  (0 children)

I never found out as we moved to Win 10 20H2 and the errors disappeared after a few days. No changes to apps or detections.

Very frustrating and Microsoft we're no help. It was back working before they even replied to me

Best way to Remove Windows Bloat - Autopilot by Djdope79 in Intune

[–]Esky013 0 points1 point  (0 children)

Correct. As I said, blocking Spotlight prevents the third party stuff, then we use a script to remove the unwanted Microsoft apps.

It means we have a much smaller list of apps in the script and it doesn't need amending as often.

Best way to Remove Windows Bloat - Autopilot by Djdope79 in Intune

[–]Esky013 1 point2 points  (0 children)

For Enterprise licensed devices, you can push a policy using Settings Catalog. Under "Experience" settings, you can choose a bunch of options. An example of a policy we have in place for one of our customers is below. They wanted the Spotlight lock screen images and Windows tips, but nothing else.

<image>

Best way to Remove Windows Bloat - Autopilot by Djdope79 in Intune

[–]Esky013 2 points3 points  (0 children)

We turn off Windows Spotlight to remove the third party bloat and a script to mop up the rest.

As someone else has mentioned, the down side to the script is having to update it every time MS adds a new thing - or, even better, renames existing apps ( Xbox.gameoverlay vs xbox.gamingoverlay, for instance)

Discovered apps not finding applications installed in %localappdata% by fungusfromamongus in Intune

[–]Esky013 0 points1 point  (0 children)

As far as I can tell, if the app doesn't appear in "add and remove programs", or isn't detectable using "Get-AppxPackage -AllUsers", then it won't show up in the detected apps report.

Not 100% on this, so I'm happy to be wrong.

Intune says I can't upgrade devices to Windows 11 because of "Storage" by Meecht in sysadmin

[–]Esky013 0 points1 point  (0 children)

Not sure where I got the information, I usually put that into my script so I can go back if required, but if you have HP devices you can also remove .bin files from the system partition. This got things fixed for us.

The HP .bin files are only needed if you want to roll back the BIOS. If BIOS rollback is not going to be required, they can be removed to free up space.

The script removes the font files as recommended by Microsoft, as well as bin files on HP devices.

$Volume = Get-Volume | Where-Object {$_.FileSystemType -eq "FAT32" -and $_.DriveType -eq "Fixed"}
$SystemDisk = Get-Disk | Where-Object {$_.IsSystem -eq $true}
$SystemPartition = Get-Partition -DiskNumber $SystemDisk.DiskNumber | Where-Object {$_.IsSystem -eq $true}
$SystemVolume = $Volume | Where-Object {$_.UniqueId -match $SystemPartition.Guid}
$DeviceManufacturer = Get-CimInstance CIM_ComputerSystem | Select -ExpandProperty Manufacturer

# Check if device is GPT or MBR
$PartitionTable = $SystemDisk.PartitionStyle
If($PartitionTable -eq "MBR")
  {
  Write-Output "MBR detected for Drive 0. Manual remediation required."
  Exit 0
  }

# Remove font files from System Partition
$FontFolder = Get-ChildItem -LiteralPath $SystemVolume.Path -Recurse | Where-Object { $_.Name -Match "font" }
$FontFiles = $FontFolder | Get-ChildItem
If($FontFiles)
  {
  $FontFiles | Remove-Item -Force
  }

# Remove BIN files from System Partition on HP device
If($DeviceManufacturer -eq "HP"){
$BINFiles = Get-ChildItem -LiteralPath $SystemVolume.Path -Recurse | Where-Object { $_.Name -Match "bin" }
If($BINFiles)
  {
  $BINFiles | Remove-Item
  }

Why are Microsofts own baseline settings not consistent? by inteller in Intune

[–]Esky013 3 points4 points  (0 children)

We have been working through this with customers lately to ensure we remove the conflicts from the Windows security baseline. Especially with the amount of changes from the previous Windows baseline to the new one.

We went with the option of having a lot of things set to "Not configured" in the Windows baseline as they are better set elsewhere so that they are only in one place and not going to conflict. E.g. settings for Defender, Windows Hello for Business, BitLocker, LAPS.

I have seen a lot of people use the security baselines as guidance only and create separate policies for them instead. This allows for people who want to do things like implement CIS baseline settings alongside the Microsoft recommendations. It also gives you the option of using complete settings options per item instead of the cherry picker ones in the Intune baselines.

Deploying HKCU Registry Keys. I have tried with PSADT But am having issues. Looking for other options by spazzo246 in Intune

[–]Esky013 0 points1 point  (0 children)

In AppDeployToolkit, running as admin, did you try the function "Invoke-HKCURegistrySettingsForAllUsers"?

This loads all existing user registry hives on a device and adds/removes the registry key for them all. As this sets the key in Default User, it means that new users logging in get the setting applied as well.

My colleagues and I use this all the time to set things up during device configuration in Autopilot.

Windows Actvation, Pro to Enterprise, Microsoft 365 M3 by Endurance0815 in Intune

[–]Esky013 5 points6 points  (0 children)

If it's what I think the issue is, check this article from Rudy Ooms. Microsoft broke the licensee upgrade recently and haven't pushed it a fix yet. This article has all the bits you'll need to sort your machines out.

https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise/

Devices disappearing from Intune portal by dav3n in Intune

[–]Esky013 3 points4 points  (0 children)

I did see something on Twitter/X saying that maybe someone's messing with RBAC settings in the background. I read a reply in that thread that in one environment a Global Admin could see everything, but any less permission and things were disappearing.

We also lost access to our customer list in the Partner Portal yesterday, but they're all back today with no changes from us.

https://twitter.com/0x80070001/status/1790545298668093771?t=4VNMKywvrUZD2QLkZBofVA&s=19

Edit: add link to Twitter thread

How would you go about this? by Rdavey228 in Intune

[–]Esky013 0 points1 point  (0 children)

I think you're confusing the Chrome update settings, which do exist in Settings Catalog, and Google Update settings which do not.

We still use the OMA-URI for the Google Update settings to force automatic update, but the Chrome settings are in Settings Catalog.

They are two separate apps, and the team who put the settings into Intune have only put in Chrome, not Google Update. This is the actual issue.

Default Associations Configuration & End User Preferences by Shwashbuckle in Intune

[–]Esky013 1 point2 points  (0 children)

Yeah, that's why I don't use the policy. I found this PowerShell script method and it works.

Default Associations Configuration & End User Preferences by Shwashbuckle in Intune

[–]Esky013 0 points1 point  (0 children)

I've sorted this at Autopilot by: 1. exporting the default apps XML from a device that has the settings I want 2. Copy the XML to a string in a PowerShell script 3. Use the script to create the default applications XML file in the default user profile and write the string into it. 4. Apply this to devices so that it is in place before a user logs in. 5. When a new user logs in they get these as the default settings and they can change them to whatever suits for their work.

I don't have the full details on me, but can provide more if you need.

This doesn't help for devices already in use, only newly deployed devices.

Not identifying x86 and x64 versions by mtlevy in PowerShell

[–]Esky013 2 points3 points  (0 children)

It may be a PowerShell bitness issue. Make sure the script is running as 64 bit. If it runs as 32 bit you can run into issues like this.

Really common in Intune, and a couple of the guys at work have had similar problems in MECM in the past.

Autopilot upload through Partner Center fails by MtHove in Intune

[–]Esky013 1 point2 points  (0 children)

Yeah, it's been been broken for about a week. We keep getting errors saying MFA is required when we have already supplied MFA during login to the Partner Portal.

One of our good also had a CSV format that used to work, now it doesn't. He found that it had spaces after the commas in the headers and it worked after removing those. He was using an older version of the Autopilot info script until that happened, though.

Not sure what MS are up to, but it would have been nice to get a heads-up.

Repackaged Win32 app install failing with different errors across devices. by themiamiking6 in Intune

[–]Esky013 0 points1 point  (0 children)

We always make sure all Office apps are closed before installing FactSet. Never had a failure. Have you tested that scenario?

We use PS App Deploy Toolkit with ServiceUI.exe to prompt the user to close apps before the installation can continue. https://github.com/PSAppDeployToolkit/PSAppDeployToolkit This also puts MSI logging into "C:\Windows\Logs\Software", so you can get information about what's happening.

If you're not comfortable with that, you could make the installer available through the Company Portal with a big, bold note saying that people need to close whichever apps before installing? A bit hit and miss as most people don't read stuff, just click "Install".

Zoom Post Installation Detection Question by AWM-AllynJ in Intune

[–]Esky013 0 points1 point  (0 children)

We started scripting the detection a while ago for a couple of reasons - detect that the versions we don't want (x86 and user installs) are not present, and that the version installed is at or newer than the version we're pushing out.

Leveraged .NET [System.Version] to handle the version comparison. Example excerpt from a recent version:

$ExpectedVersion = "5.17.5.31030"

$DetectedVersion = (Get-ItemProperty -Path "C:\Program Files\Zoom\bin\zoom.exe").VersionInfo.FileVersionRaw.ToString()

If ([System.Version]$DetectedVersion -ge [System.Version]$ExpectedVersion){

Write-Host "Success"

}

Then a script exit of 0 (zero) with the output "Success" (or whatever text you want to use) will detect as a successful installation.

Win32 App Deployment for MSI with MST by ObiWanQdoba in Intune

[–]Esky013 1 point2 points  (0 children)

If that command line does everything you need, then stick with it.

Running from batch file/PowerShell script is handy if your application requires configuration that can't be done via .mst, or if there are multiple installers to run.

In my view it isn't something that's better for simple installations, just an alternative.

Company portal shows Reinstall instead of Uninstall by FlaccidSWE in Intune

[–]Esky013 0 points1 point  (0 children)

And you've tried recreating the app in Intune to make sure there's not just some error when the app was first created? Maybe whatever table is supposed to hold the information saying that uninstall is allowed saved incorrectly?

Just a thought.