Set-ADUser commands: Unable to contact the server (does not exist, is down, or doesn't have ADWS running)

Joe Grover 156 Reputation points
2021-01-21T17:47:54.2+00:00

So, historically I've used the following script to set the thumbnail photo for a AD user object:

Set-ADUser jdoe -Replace @{thumbnailPhoto=([byte[]](Get-Content "C:\photos\jdoe_photo.jpg" -Encoding byte))}

I would run this command directly from one of our domain controllers.

Now however the command doesn't work. Any Set-ADUser commands I issue fail with the error "Set-ADUser : Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running."

I've tried a number of things (such as specifying different DCs, specifying credentials, etc) and can't figure out why it isn't working. The services all appear to be running on all our DCs.

One thing that has changed is we're taking our first steps in migration to 365. I have Azure AD Sync set up and have some pilot users syncing over and migrated.

Does maybe having Azure AD Sync running affect anything like this? The DC I generally run the command on is not the server running the sync (though I did try it there to see if it was any different). I can run Get-ADUser on this user object without issue, but I can't Set-ADUser and running these commands doesn't appear to be putting anything in the event logs. The user I'm trying to modify is not a synced user--the AD object exists only on-prem.

Windows for business | Windows Client for IT Pros | Directory services | Active Directory
Windows for business | Windows Server | User experience | PowerShell
0 comments No comments
{count} votes

Accepted answer
  1. Rich Matheisen 47,901 Reputation points
    2021-01-22T15:47:59.727+00:00

    This is turning into a head-scratcher! It's been a long time since I've resorted to using ADSI, and I don't have an AD to run this against, but try this:

    $dc = "dc-name.domain.local:389"
    $dn = Get-ADUser joe | Select-Object -ExpandProperty distinguishedName
    [byte[]]$jpg = Get-Content C:\photos\jdoe_photo.jpg -encoding byte
    $user = [adsi]"LDAP://$dcname/$dn"
    $user.Properties["jpegPhoto"].Clear()
    $null = $user.Properties["jpegPhoto"].Add($jpg)
    $user.CommitChanges()
    

    It'll use ADWS to get the user (and reduce the coding!), but it should use LDAP on port 389 instead of ADWS to update the user's jpegPhoto property.


3 additional answers

Sort by: Most helpful
  1. Rich Matheisen 47,901 Reputation points
    2021-01-21T19:08:25.35+00:00

    So Get-ADUser jdoe | Set-Aduser -Replace . . . . doesn't work either?

    This should discover a DC in your site that's running ADWS: Get-ADDomainController -Discover -Service ADWS

    Are you running any of this in an imported PowerShell session?

    Any chance there have been changes to the SRV records for the domain in the DNS you're using?


  2. Joe Grover 156 Reputation points
    2021-01-21T19:22:34.13+00:00
    • The Get-ADUser method did not work either.
    • Get-ADDomainController -Discover -Service ADWS returns a domain controller (the one I'm running the command on, actually).
    • This is being run directly on a domain controller. The only thing I ever do on this particular DC is look at the DHCP server and run this command (neither of which I've done in months).
    • The only SRV changes that have been made was I changed an autodiscover record for one of our domains to a SRV record pointing to our Exchange server.

  3. Anonymous
    2021-01-22T07:02:16.657+00:00

    Hi,
    Based on the situation , i would recommend you check if there are any issues with the DCs and replication .
    You can run the following commands to check if there are any errors:
    Dcdiag /v >c:\dcdiag1.log
    Repadmin /showrepl >C:\repl.txt

    Best Regards,


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.