Hmm... that's decidedly a "not supposed to happen" scenario. The RID 500 Administrator account is stamped with the "isCriticalSystemObject" attribute set to true, and to my knowledge LSASS is supposed to return an ERROR_DS_UNWILLING_TO_PERFORM error (0x80072035) if you were to try and delete it. (I don't have a scratch AD sitting around in any of my VMs right now to give it a shot. Maybe later...)
How are you searching AD, anyway?
From AD Users and Computers, do a "Find" at the root of the domain, choose a "Custom Search" in the "Find" dropdown, go to the "Advanced" tab, and enter the LDAP search filter "(objectSid=S-1-5-21-2025429265-492894223-1708537768-500)". That'll give you a subtree search of the domain from the root of the directory.
If you really have deleted your RID 500 Administrator account somehow I'd stronly consider contacting Microsoft Product Support Services. They can probably have something coded to re-create the account (if they don't already have such a tool). I can't imagine how you managed to delete it anyway, because the only way I could think to do that would be direct interaction with the database through ESE. I really didn't think there was any publicly-exposed API that would let you delete an object marked with "isCriticalSystemObject" set to True, and I don't think you can set it to False on the RID 500 Administrator, either. Hmmm...
You've got an interesting situation there. Let us know what the subtree search above returns.
While @sysdmin1138 answer was correct it's worth mentioning that changing the scope is not the only reason why things are missing from the view. There are things that invisible by default.
Some objects such as physicalDeliveryOfficeName are hidden from view so you can't delegate them easily. A lot of other attributes are also hidden, but physicalDeliveryOfficeName is very specific and can be good example on how things works for Delegation.
The Per-Property Permissions tab for a user object that you view through Active Directory Users and Computers may not display every property of the user object. This is because the user interface for access control filters out object and property types to make the list easier to manage. While the properties of an object are defined in the schema, the list of filtered properties that are displayed is stored in the Dssec.dat file that is located in the %systemroot%\System32 folder on all domain controllers. You can edit the entries for an object in the file to display the filtered properties through the user interface.
A filtered property looks like this in the Dssec.dat file:
[User]
propertyname=7
To display the read and write permissions for a property of an object, you can edit the filter value to display one or both of the permissions. To display both the read and write permissions for a property, change the value to zero (0):
[User]
propertyname=0
To display only the write permission for a property, change the value to 1:
[User]
propertyname=1
To display only the read permissions for a property, change the value to 2:
[User]
propertyname=2
After you edit the Dssec.dat file, you must quit and restart Active Directory Users and Computers to see the properties that are no longer filtered. The file is also machine specific so changing it on one machine doesn’t update all others. It’s up to you whether you want it visible everywhere or not.
Full story about physicalDeliveryOfficeName and how to change it with screenshots can be read at my blog.
PS1. Since physicalDeliveryOfficeName is special case, after modifying this setting look for Read/Write Office Location. Unfortunately the name physicalDeliveryOfficeName never shows up.
PS2. Unless those settings are uncovered by modifying dssec.dat you won't be able to see them. Since this file is per computer it's entirely possible it's visible on some computers and not visible on others depending whether someone made the change earlier or not. This could explain why you could see it before and not later on.
PS3. Sorry for resurrection but just spent few hours trying to find the cause so thought I would share it for future reference.
Best Answer
You can't. You have to do an authoritative restore of the user account in order to get a user back. Have a look at this Technet article.