Runtime Exception When Using Set-OrganizationConfig

Rhys Pickett 40

Trying to run Set-OrganizationConfig cmdlet in powershell EXO V3 module returns runtime exception: "unable to find type [uint]". Has anyone had this error before and know of a potential solution? I cannot find anything online to reference this.

I can run Get-OrganizationConfig absolutely fine. I can see other topics with people being able to run the get cmdlet and not the set cmdlet - their solution was permissions based. I have checked my permissions and I am part of the Compliance Administrators group and also I am a part of the tenant admin group, so I think permissions should suffice for what I'm trying to achieve here.

Many thanks for reading - any help greatly appreciated

Andy David - MVP 149.1K Reputation points MVP

2024-07-17T12:12:29.3066667+00:00

I see the same issue here. Let me poke around and get back to you
Karelpelck 710 Reputation points

2024-07-17T12:29:18.4233333+00:00

@Andy David - MVP , It woks on PowerShell 7.X it seems.

Accepted answer

Karelpelck 710 Reputation points

2024-07-17T11:53:47.03+00:00
Hey Rhys,

There are few things you can try.

Check if you have the same issue with a confirmed Global Admin.

Check your execution policy. You can use "Set-ExecutionPolicy Bypass -Scope Process" to temporarily bypass the policy within the scope of your current PowerShell session.

Make sure you have all dependancy modules installed and imported.

I'm not sure what parameter you are trying to set. But it could be a type mismatch in your command when setting the value for one of the attributes in the command.

If you can give us more insight in the attributes/parameters you try to run the command with, we could identify the issue more clearly.

Hope this helps you to resolve your issue.
Please sign in to rate this answer.

1 person found this answer helpful.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Rhys Pickett 40 Reputation points

2024-07-17T12:09:53.9833333+00:00

Hi Karelpelck, many thanks for your reply.

I can confirm that my account is global administrator level (when checking in Entrana roles). I connect to ExchangeOnline using these credentials and still receive the error message.

I have also tested with Set-ExecutionPolicy Bypass -Scope Process as advised but still the same error message unfortunately. I have also tried Set-ExecutionPolicy unrestricted with no luck.

From the 2 below links, It appears that only the ExchangeOnlineManagement module is required to run this cmdlet (unless I am mistaken) and can confirm this is present on the machine. This module allows me to run Connect-ExchangeOnline to gain access to our tenant initially.

https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps

https://learn.microsoft.com/en-us/powershell/module/exchange/?view=exchange-ps

With the 2 above links also, the parameter values I'm passing through look to be accepted. Here is the cmdlet I am trying to run:

Set-OrganizationConfig -MailTipsAllTipsEnabled $true -MailTipsExternalRecipientsTipsEnabled $true -MailTipsGroupMetricsEnabled $true -MailTipsLargeAudienceThreshold '25'

Interestingly, I also receive the same error message when running 'Set-OrganizationConfig' on its own with no parameters.

I'm a bit at a loss with this one with myself being global administrator. I have also tested on multiple machines but still the same error message - so the issue does seem specific to the environment. Is there anything else I can try and check on?

Many thanks

Karelpelck 710 Reputation points

2024-07-17T12:26:10.75+00:00

Hey Rhys,

I have been using the PowerShell 7 version for a while now. And could not reproduce this issue running it with PowerShell 7. When I tested on Windows Powershell (Version 5.1) I got the exact same error as you described.

I would install PowerShell 7 and run it with this version. I'm assuming here that the type "uint" is not build into Windows PowerShell. I could not find any direct documentation that explains this to provide for you.

If you are using PowerShell 5.1 and 7.X side by side, you might want to look into Windows Terminal as a Command Line tool as well as Visual Studio Code.

Andy David - MVP 149.1K Reputation points MVP

2024-07-17T12:32:06.5166667+00:00

Yes, can confirm it works with 7. What's weird is that I know it worked before

Rhys Pickett 40 Reputation points

2024-07-17T12:33:59.5133333+00:00

Thanks Karelpelck/Andy! I suspect this may be the issue then! :)

I will give PS7 an install now and will confirm your response as answer if all OK and working. A very quick turnaround on this issue so honestly, I really appreciate this thank you both for your time.

I had forgot to include that piece of information so apologies for that! turns out to be the most important part haha :D (for reference I like to use powershell_ISE when Im running commands, which I believe is not available in V7 so I will have been using 5.1)

Rhys Pickett 40 Reputation points

2024-07-17T12:42:05.7866667+00:00

I can confirm using PS7 works - I've marked the original answer and accepted (not sure how to convert your PS7 comment to the right answer but hopefully that should be OK for anyone also stumbling across this article)

Thanks again both, have a great day.

nikize 6 Reputation points

2024-07-18T07:36:48.5233333+00:00

This is not a solution, sure running later version of PS might be a workaround, but in many cases it won't be.

Someone else mentioned using the console in exchange admin web, which might be a different workaround, but still not a fix.

This needs to be addressed in the source since it is a clear bug.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

1 additional answer

Rich Matheisen 46,806 Reputation points

2024-07-17T15:35:03.1433333+00:00

PowerShell 5.1 doesn't understand the abbreviated "uint" type. It never has. You can use "uint64", "uint32", or "uint16".

"int", for example, is a type "accelerator". It isn't a "real" type. "Int32" is a real type. But there's no "uint" type accelerator.

@Andy David if that worked before it was probably a change in the cmdlet, not PowerShell, that caused the problem.

Looking at the Set-OrganizationConfig help, I only see "Int32" types. Knowing what values were fed to the cmdlet might help (maybe),
Please sign in to rate this answer.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

nikize 6 Reputation points

2024-07-18T06:51:46.06+00:00

The cmdlet code has this:

[uint] ${MailTipsLargeAudienceThreshold},

Which means this is a bug that needs to be fixed in the code generated from Connect-ExchangeOnline
I think this worked when I connected yesterday, so it seems to be a recently introduced bug.

Rich Matheisen 46,806 Reputation points

2024-07-18T15:01:53.28+00:00

The online help says that parameter is an optional value of type Uint32.

I don't have any Exchange organization cmdlets to look at this, but someone should run Get-Help Set-OrganizationConfig -Parameter MailTipsLargeAudienceThreshold and, if it reports the object type "uint", that bug should be reported!

nikize 6 Reputation points

2024-07-18T16:30:11.9933333+00:00

This is a bug (unless the requirement of PS version has changed) the only question for me is where the correct place to report it is, If I knew there was a git repo for it, I would even open a PR to have it fixed, but Microsoft is a bit lacking in information about sources for their cmdlets.

nikize 6 Reputation points

2024-07-18T16:34:59.86+00:00

uint is most likely an alias for UInt32, valid in newer versions of C#, we don't have to check what the command gives, because we have already seen what it errors on, and what the script contains, it has uint, which is not valid in older versions of PS, this is an error in the cmdlet code, and is not impacted by any variable or similar on client side.

Rich Matheisen 46,806 Reputation points

2024-07-18T18:11:28.86+00:00

I haven't worked with Exchange for ten years (retired) and I no longer have any access to Microsofts' support folks (I was and Exchange MVP for 16 years). However, MVPs have that access, and I'd start there. The only name that comes to mind from my time as a MVP is @Andy David -- let's see if tagging him gives him a poke.

Rich Matheisen 46,806 Reputation points

2024-07-18T18:18:15.9066667+00:00

The "uint" type accelerator is valid in Powershell 7 -- but NOT in PowerShell 5.

"uint" in PowerShell 7 is the same as "uint32".

So, yeah, clearly a bug. No argument there.

Matthew Trembly 51 Reputation points

2024-07-19T16:35:39.89+00:00

I've been fighting with this issue for over an hour. Discovered this thread, installed Powershell 7, and everything worked fine. Do with that what you will...
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Runtime Exception When Using Set-OrganizationConfig

1 additional answer

Your answer