Update Set-UnifiedGroup.md

[Anthonyyp]

Added a note to inform users that the type value is not optional in the -emailaddresses parameter when using exchangeonline (for clarification, it appears to work via CLI, but is not reflected in the GUI, and gui changes overwrite everything in the GUI unless you use the Type value).

Added a note because I'm not positive on whether this cmdlet is relevant to on premise exchange and perhaps the type value is still truly optional there.

[learn-build-service-prod]

Learn Build status updates of commit 0375f3c:

✅ Validation status: passed

File	Status	Preview URL	Details
exchange/exchange-ps/exchange/Set-UnifiedGroup.md	✅Succeeded	View (exchange-ps)

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[chrisda]

@Anthonyyp, I see you closed this PR, but I was investigating, anyway.

Microsoft 365 Groups are a cloud-only feature, so no concern for on-premises Exchange.

The EmailAddresses parameter exists in 9 other cmdlets, some of which are cloud-only, and some of which are available in on-premises Exchange and the cloud. That was a long way of saying that the description of EmailAddresses in Set-UnifiedGroup was simply copied from those other cmdlets, but my testing reveals subtleties that were missing:

• If you leave off SMTP/smtp, the SMTP email address type is assumed.
• The first SMTP email address in a list of email addresses with no Type value OR where all type values are smtp becomes the primary email address (SMTP, not smtp).
• You can specify SMTP on an address in the middle of the list, and that will become the primary.
• All existing M365 Groups in my tenant had an 'email address' with Type value SPO, so I removed X400 and X500 and added SPO.
• I observed weird behavior where old, previous email addresses would spontaneously reappear in the EmailAddresses value after I added/removed a few other email addresses. Very random and hard to reproduce.

Anyway, I made some updates to description based on my findings.

Thanks for the feedback.

[Anthonyyp]

Honestly I removed it because I wasn't positive - after more and more testing, I cannot add an email address to an m365 group via commandline. No matter how I format, with or without type, it fails. I end up with a good looking result in commandline but nothing is reflected in GUI. I thought I had this resolved (in test) but when I ran my production script I got different results, which is why I closed my PR. Command I was running: Set-UnifiedGroup -Identity $group.PrimarySmtpAddress -EmailAddresses @{Add="smtp:$newemailaddress"} with Group being the group I'm targeting and newemailaddress of course being the address I'm attempting to add. Thanks for your reply - the uncertainty on what is or isn't required there is what lead me to close the PR.

…

________________________________ From: Chris Davis ***@***.***> Sent: Thursday, August 31, 2023 1:43 PM To: MicrosoftDocs/office-docs-powershell ***@***.***> Cc: Anthonyyp ***@***.***>; Mention ***@***.***> Subject: Re: [MicrosoftDocs/office-docs-powershell] Update Set-UnifiedGroup.md (PR #11224) @Anthonyyp<https://github.com/Anthonyyp>, I see you closed this PR, but I was investigating, anyway. Microsoft 365 Groups are a cloud-only feature, so no concern for on-premises Exchange. The EmailAddresses parameter exists in 9 other cmdlets, some of which are cloud-only, and some of which are available in on-premises Exchange and the cloud. That was a long way of saying that the description of EmailAddresses in Set-UnifiedGroup was simply copied from those other cmdlets, but my testing reveals subtleties that were missing: * If you leave off SMTP/smtp, the SMTP email address type is assumed. * The first SMTP email address in a list of email addresses with no Type value OR where all type values are smtp becomes the primary email address (SMTP, not smtp). * You can specify SMTP on an address in the middle of the list, and that will become the primary. * All existing M365 Groups in my tenant had an 'email address' with Type value SPO, so I removed X400 and X500 and added SPO. * I observed weird behavior where old, previous email addresses would spontaneously reappear in the EmailAddresses value after I added/removed a few other email addresses. Very random and hard to reproduce. Anyway, I made some updates to description based on my findings. Thanks for the feedback. — Reply to this email directly, view it on GitHub<#11224 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVG42IPXWWBSB5OMK6WZPUTXYDENLANCNFSM6AAAAAA4GE634M>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[learn-build-service-prod]

Learn Build status updates of commit 0375f3c:

✅ Validation status: passed

File	Status	Preview URL	Details
exchange/exchange-ps/exchange/Set-UnifiedGroup.md	✅Succeeded	View (exchange-ps)

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[chrisda]

@Anthonyyp, perhaps try @{Add='smtp:$newemailaddress'} (single quotes instead of double quotes? Or perhaps no quotes at all?)