Microsoft

Windows Store Error 0x8024500c

Posted on by Adam Fowler

I was getting this error company wide when trying to install any app from the Windows Store on a domain joined computer. The store was fully navigational, but any app I tried to install would instantly error. Showing the details would reveal Error Code 0x8024500c.

This is a fairly standard error code and there’s a lot of reasons already posted online; but for me it was one simple Group Policy setting:

Do not connect to any Windows Update Internet locations

Help:

Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Windows Store.

Enabling this policy will disable that functionality, and may cause connection to public services such as the Windows Store to stop working.

Note: This policy applies only when this PC is configured to connect to an intranet update service using the “Specify intranet Microsoft update service location” policy.

Back in the Windows 7 days, it makes sense to disable this if you want to force clients to only use your WSUS servers and control the experience. However, it completely breaks the Windows Store!

You can find this policy under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update.

Note that this doesn’t seem to break the private Business Store section if you have that configured up, which can be a nice way of controlling the apps your users see.

Update 14th December 2017

A friend pointed this out to me – before changing this setting, be aware that there’s a bug with Windows 10 Pro that is fixed in KB4053580: 

Exchange Online and Exchange On-Premises Security Groups

Posted on by Adam Fowler

I had a requirement come up where I needed a list of Exchange Online users as well as Exchange On-Premises users. If you’re hybrid or going through a long migration, there’s many scenarios where you want certain products or settings applied against the users and accounts based on where their mailbox is.

You could maintain that manually, but why do that when you can automate it!

Thankfully there’s two easy commands that will return accounts based on where they are – get-mailbox and get-remotemailbox. As long as you’re in Exchange Hybrid mode, you can run both of these commands against your local Exchange server.

Here’s the quick script I wrote up:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange server name/Powershell -Authentication Kerberos
Import-PSSession $session
$remoteusers = Get-RemoteMailbox -resultsize unlimited
$onpremusers = Get-mailbox -resultsize unlimited
$remotegroup = "Exchange Online Users"
$onpremgroup = "Exchange OnPrem Users"

Get-ADGroup $remotegroup | Set-ADObject -clear member
Get-ADGroup $onpremgroup | Set-ADObject -clear member

foreach ($user in $remoteusers){
Add-ADGroupMember -Identity $remotegroup -Members $user.SamAccountName
}

foreach ($user in $onpremusers){
Add-ADGroupMember -Identity $onpremgroup -Members $user.SamAccountName
}

Remove-PSSession $Session

All I’m doing here is getting the two user types and putting them into variables – $remoteusers and $onpremusers. I’ve also used the group names as variables, so you can create whatever AD groups you like and put them into the $remotegroup and $onpremgroup variables.

Also I’m clearing out all members of the group before adding users, which means if someone gets migrated or leaves, they’ll be cleaned up from the old group properly.

Finally I’m going through the two users lists and using ‘foreach’ to add each user to the relevant group, using the SamAccountName value of each result to identify them.

It’s only a basic script, but you can easily add extra filters to the Get-Mailbox and Get-RemoteMailbox commands to do things such as only getting users from certain OUs.

This was tested on Exchange 2010, so if you get different results on Exchange 2013 or 2016 please let me know.

Outlook 2013 & 2016 Blank Screens and Crashing

Posted on by Adam Fowler

Update 2nd May 2018:

Microsoft have just released the LAA patch for the issues below, KB4018376 for Outlook 2013, and KB4018372 for Outlook 2016. It seems to work, as I can see a lot more memory available for Outlook 2016 after this patch, and will update later once I can confirm the below issues are resolved.

Original Blogpost:

Since going from Outlook 2010 to 2016, I’ve noticed several issues. They’re outlined on this TechNet article which lists:

  • Buttons on the Outlook ribbon failing to paint properly
  • Email messages displaying either blank or black in the Reading Pane
  • The Navigation Pane failing to draw all folders properly
  • Various rectangles appearing in the Outlook user interface (UI)

There’s also just Outlook crashing/freezing/running slow. This has been an ongoing problem, and I suspected 3rd party addins to be the culprits. That’s sort of true, however it turns out it’s an overall memory issue with 32 bit Outlook having ~2GB of RAM to access, shared amongst all the 32 bit apps running on your computer.

If you want to know that low memory is the cause of your issues, one way is to use the Sysinternals VMMap utility and follow these instructions. If your free memory is under 250MB, then you’re working below the requirements of what Outlook needs to have available to continue running smoothly.

The article above is very well written and detailed, with the primary remediation suggestion being to go 64 bit Office. This isn’t a short term realistic solution for many companies who have legacy 32 bit addons, or vendors who just haven’t got there with 64 bit addins yet. It only takes 1 addin for that idea to come crashing down, and then there’s the testing of all the re-written apps, and then deploying out; an uninstall of the whole Office 2013 or 2016 32 bit suite, uninstalling all the addins, deploying Office 64 bit, deploying the new addins… it’s potentially a huge project to take on.

There is hope though for those of us who can’t go 64 bit (again the article has many suggestions), which is a new feature called Large Address Aware (LAA). It doubles the amount of memory (4GB) available to the Office apps. It’s already rolled out to Outlook 2016 build 1709. That makes sense if you’re using the Click to Run (CTR) version of Office 2016, but the MSI version that many still use hasn’t got this update yet. Referring to the TechNet article again on this issue, there’s no exact specific mention that LAA will come to the Click to Run version of Outlook 2016, so we’ll have to wait and see.

If you’re experiencing a less than great experience with Outlook 2013 or 2016, it’s worth understanding the above and seeing if you’re affected. This may drive you to change to Office 2016 CTR, Office 2016 64 bit, or even both – or leave you to work out how you can improve the experience, with potentially disabling Outlook addins that aren’t necessary.

I am trying to work with Microsoft on this issue too, so feel free to ask any questions or make any comments and I’ll see if I can assist.

Microsoft Bookings for E3 and E5 Customers

Posted on by Adam Fowler

There’s a few Office 365 features that were released only for Business customers; there’s a nice list of all the Office 365 Features and what subscription they sit under on Technet. The good news is that they’re coming to Enterprise customers too!

The first service to be available is called Bookings which lets you build a booking system for your customers to use. There’s actually a lot to it – you can set rates, who’s available, what times to book, what sort of appointments customers can choose.. I can see it being a big benefit to a small business to have a very easy to configure and professional booking system.

I can see why Microsoft originally didn’t let Enterprise customers have this product – it’s not going to work well if you have 1000 staff that can be booked using it, and have more complex requirements.

Regardless, I’m sure many Enterprise customers want to at least have a look at a new free addon that’s part of their subscription.

There’s a few steps to getting access to Bookings, and it’s different to other products such as Teams. Again, Microsoft have a Technet Guide on getting Bookings but here’s the abbreviated version;

In Office 365 Admin, go to Billing > Purchase Services. Find Business Apps (it’s near the bottom), and follow the bouncing ball from the ‘Buy Now’ button which shows up when you hover over or click the Business Apps tile. It’s a bit strange to go through a purchase process for an E3/E5 subscription.

Although there’s an option to “Automatically assign to all of your users with no licenses” I found that at the end of the process, nobody actually had the license applied. You’ll need to follow your normal license allocation procedure (which at the basic level, can be choosing a user from the admin console, going to Product Licenses, finding ‘Business Apps’ and changing the switch to ‘on’).

I also hit an issue when going through the purchase process when choosing to pay. I had the message ‘Sign-in required For security reasons, please try signing in again. If you receive this notification again, a specific browser setting is preventing you from utilizing this page. Please follow this support article to fix the issue.’ Trying again ended up going in a loop to see that message. Google Chrome I couldn’t resolve this; Internet Explorer however, set your browser settings as per the support article but then completely close all IE windows, or it doesn’t seem to work.

Once you’ve purchased, it only takes a minute or less for the licenses to appear. As above, make sure you’ve then checked and applied the license to an account you plan to test on. The app itself may take longer to show up in the dots menu, but you can go direct to bookings.office.com and you will hopefully see a page like this:

From there, you can start to check out settings and configure it up!

Default Printer At First Logon via Group Policy

Posted on by Adam Fowler

Deploying a network printer via Group Policy is pretty easy. In Group Policy Management Editor, you go to User Configuration > Preferences > Control Panel Settings > Printers and right click to create a new Shared Printer. Configure the options which are pretty straight forward.

Something doesn’t go right though, if you use the option ‘set this printer as the default printer’. The printer won’t actually be set as default for the first login. As it’s set to Update though, this will get fixed next time Group Policy runs.

However, if you have the Action set to ‘Create’, it only gets one chance to set the default printer – at the time of creation. That fails, and it doesn’t get a chance to set the default printer again.

Why does it fail to set the default printer at first logon? You’ll see an event viewer application error like this:

The user ‘HP Printer’ preference item in the ‘Define Printers {XXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}’ Group Policy object did not apply because it failed with error code ‘0x80070709 The printer name is invalid.’ This error was suppressed.

There’s a clear Microsoft Support Article that explains why – in summary, Windows isn’t ready yet to change something on the printer between the time it creates the printer, and then tries to make it default as they’re two separate actions.

However, we can work around this by deploying a registry entry that sets the default printer. This 11 year old article is still correct in that it shows the registry value to change:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

REG_SZ - Device
Value - \\adamfowlerit\printer,winspool,Ne04:e


Setting this via registry as an ‘Apply once and do not reapply’ with any other logic matching your printer deployment policy, should end up with the printer as a default on first logon.




This is a problem that’s been around for many years, but the first time I’ve hit it!


Also, if you’re wondering what the ‘Ne04’ part means, it seems to be some sort of counter which goes up for each time you install a printer.