We are using quest powershell to set the Hide from address list value to True. When checked from Exchange System Console, I can see the box is checked for "Hide from Exchange Address List". Also, I looked at this attribute using ADSI and it's correctly set to boolean value "True".Can any one help me how to diagnose this issue. This has happend only to few users not to all for which this script ran.

So are you saying the accounts are still visible in Outlook?How about via OWA? Is Outlook in cache or online mode?

Yes, Still visible in GAL. (cheked in Outlook and Webmail, both).

This may be to obvious, but have you generated a new GAL? I would check the event log on the server to verify that the GAL is actually being created and updated every night.

the mailboxes were hidden from GAL 2 months back..so there has been ample time for it. Top of that I am looking at Online GAL.

Sounds silly I know, but have you unchecked, applied and then rechecked to hide as a test?

Which cmdlet are you using? Setting the attribute of the account is not enough - as on Exchange 2007 there's no RUS service that was responsible for thework"behind the curtain". You should do this with Exchange PowerShell cmdlets Set-MailUser -Identity User -HiddenFromAddressListsEnabled $true

The command being used is :Set-QADUser -Identity User -ObjectAttributes @{MSExchHideFromAddressLists=$true}

I did not do this yet..Definetly I am going to do it now..I wanted to troubleshoot it first why is this happening. By unchecking and checking it again I though I might lose some clues...

I did not do this yet..Definetly I am going to do it now..I wanted to troubleshoot it first why is this happening. By unchecking and checking it again I though I might lose some clues... Well, I havent used that Quest PS snap-in, so I Cant tell you if it supports Exch 2007 or not. If it works using the 2007 tools (either the gui or Powershell), then I would say its an issue with the Quest stuff.

The command being used is :Set-QADUser -Identity User -ObjectAttributes @{MSExchHideFromAddressLists=$true} This command is wrong. It only sets one attribute - nothing more. Set-MailUser is more complicated. As I said before it's doing some extra work - for example itis responsible for deletingshowInAddressBook attribute. If you will uncheck and check again "Hide from address book" box on Exchange System Console it will work.

I have been able to use the same Quest snap in to do this and it's working fine for almost all other AD accounts it was run, except for few. My basic question is if it's able to set the AD attribute MSExchHideFromAddressLists to "True", then why the account is still being shown in address book..

I have been able to use the same Quest snap-in & cmdlet to do this and it's working fine for almost all other AD accounts it was run, except for few. My basic question is if it's able to set the AD attribute MSExchHideFromAddressLists to "True", then why the account is still being shown in address book..

You may want to ask Quest support that question. Bottom Line, if using the Exch 2007 tools correctly hides the account, but the Quest PS command does not, then its not correctly setting all the necessary attributes.

On Sat, 24-Oct-09 16:45:40 GMT, RakeshMishra wrote:>I have been able to use the same Quest snap in to do this and it's working fine for almost all other AD accounts it was run, except for few. My basic question is if it's able to set the AD attribute MSExchHideFromAddressLists to "True", then why the account is still being shown in address book.. Setting that attribute to true or false, in a domain that has anExchange 2003 Recipient Update Service running against it, is a signalnAddressBook.Setting that attribute to true or false in a domain where there's noRUS only alters the value of the single property.Unless that cmdlet's code is smart enough to recognize that settingsome arbitrary AD property should act on another AD property I don'tthink you'll see the results you expect.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

I do agree to what you have mentioned here. But, then why it's working fine for most of the accounts for which I have set the attribute this way. I mean it should not have worked at all if this is the case. Any way, I thank you all for your suggestions. Probably I will have to stop putting any further questions and just go for use of powershell cmdlet.

I do agree to what you have mentioned here. But, then why it's working fine for most of the accounts for which I have set the attribute this way. I mean it should not have worked at all if this is the case. Any way, I thank you all for your suggestions. Probably I will have to stop putting any further questions and just go for use of powershell cmdlet. I would ask Quest support.

On Sun, 25-Oct-09 10:56:58 GMT, RakeshMishra wrote:>I do agree to what you have mentioned here. But, then why it's working fine for most of the accounts for which I have set the attribute this way. I mean it should not have worked at all if this is the case. You haven't divulged any information about you AD topology or Exchangeconfiguration (i.e. whether you have E2K3 servers or not, whether youhave an active RUS for each AD domain, etc.).As to why i doesn't work consistently I can't say. It may be the codend the cmdlet. It may your topology in AD or Exchange. Butwithout lots more information (and access to the code from Quest) allI can do is guess.>Any way, I thank you all for your suggestions. Probably I will have to stop putting any further questions and just go for use of powershell cmdlet. Why NOT use the MS cmdlet?---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP