0

The command I'm trying to execute is

[PS] C:\Windows\system32>Set-ClientAccessServer -Identity CCSEMAIL2010 -AutoDiscoverServiceInternalURI https://autodiscover.local.company.net/Autodiscover/Autodiscover.xml

The exception is

You must provide a value for this property.

  • CategoryInfo : NotSpecified: (0:Int32) [Set-ClientAccessServer], DataValidationException
  • FullyQualifiedErrorId : 4DA56CC3,Microsoft.Exchange.Management.SystemConfigurationTasks.SetClientAccessServer
  • PSComputerName : ccsemail2010.local.company.net

I don't understand what is not specified and why there is a reference to an Int32 in the error. I've verified that the server name is as i input it. I've used adsiedit.msc to hunt down the record in AD and verify that the account I'm using to run the cmdlet has permission to modify it. All of the syntax I've looked at for the cmdlet has only the -Identity property as required. If I run

[PS] C:\Windows\system32>Set-ClientAccessServer -Identity CCSEMAIL2010

The same exception is thrown.

Digital ink
  • 500
  • 1
  • 10
  • 23
  • Any references to old CAS servers hanging around AD? You could try `-identity *` with the first command – Drifter104 Sep 28 '15 at 22:18
  • No luck with the asterisk. The only other CAS server that was ever on the network was a server with the same machine name as this one. The server was rebuilt due to a botched install. I've also found that if I use the command get-clientaccessserver | fl name,AutoDiscoverServiceInternalUri I can see manual edits to the serviceBindingInformation for that server having an effect. Its just that powershell cmdlet that is having an issue. – Digital ink Sep 28 '15 at 23:07

2 Answers2

0

What do you see when running:

get-clientaccessserver | fl name, fqdn

LE: Can you also make sure that you have the required permissions?

Get-ManagementRole -Cmdlet set-clientaccessserver
Get-ManagementRoleAssignment -Role "exchange servers" -GetEffectiveUsers | fl effectiveuser*

In case you have more roles besides "Exchange Servers" with the cmdlet, you should check those too.

m-adrian
  • 36
  • 2
  • get-clientaccessserver | fl name, fqdn returns two lines. 1) name: CCSEMAIL2010 2) fqdn: CCSEMAIL2010.local.company.net The command Get-ManagementRole -Cmdlet set-clientaccessserver returns Name: Exchange Servers, RoleType: ExchangeServers. The command Get-ManagementRoleAssignment -Role "exchange servers" -GetEffectiveUsers | fl effectiveuser* returns All Group Members, Active Directory Admin, All Group Members, Active Directory Admin, All Group Members. I'm not familiar with those cmdlets so I'm not sure if that is all appropriate. – Digital ink Sep 29 '15 at 18:29
0

This is how I resolved the issue. The root cause of the problem ended up being corruption in AD. Once the corruption was cleaned up all set commands issued via powershell worked as expected.

First I listed the mailbox databases via powershell enter image description here

I then opened the Exchange Management Console to verify what I saw in powershell enter image description here

enter image description here

Noting the names of the databases I then logged into a domain controller and launched the ADSIEdit tool. I dug through the tree to find the mailbox databases. What I saw was a bit odd. There were more mailbox database records than I expected there to be. enter image description here

I investigated the mailbox database records further to find two database records that indicated they were associated with a single server. I knew from my previous research that this wasn't expected and may not be correct. enter image description here

enter image description here

I decided to take a risk and removed the database that wasn't listed when asking for mailbox databases via powershell and via the EMC.

That fixed it. All my powershell cmdlets now work as expected

Digital ink
  • 500
  • 1
  • 10
  • 23