RE: [ActiveDir] OldCmp question
I agree that ds-tools lack some possibilities, and I'd prefer MS putting your tools into their product, however in most scenarios I've been working in they are not allowed to put additional software in their domain unless it's prooved, and the use of your tools is not important enough the justify this hazzle. So I'm mainly limited to ds-tools or vbs. Something like this should work: Dsquery user -stalepwd 90 | dsget user -dn -disabled | find No Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811 D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, May 20, 2006 6:24 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OldCmp question Hmm good point... Well except we were talking about oldcmp instead of adfind... Fun though that the switches are so close... So what are the switches and the filter to use with dsquery to get an html listing of all enabled users whose password age is 90 days or older? :) -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Saturday, May 20, 2006 2:56 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OldCmp question I didn't catch it because I didn't bother enough to read the adfind syntax. If you'd provided a standard LDAP-Filter with DSQuery ... ;-) Gruesse - Sincerely, Ulf B. Simon-Weidner Profile Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B48 9-F2F1214C811 D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, May 19, 2006 9:41 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OldCmp question I just realized I told you how to INCLUDE disabled accounts - you want NOT DISABLED accounts. So you want to NOT what I indicated, however you have to add to it to avoid a false positive. -af ((useraccountcontrol=*)(!(useraccountcontrol:AND:=2))) One thing to note with NOT filters... Well two actually... 1. NOT filters are inefficient. But then so are bitwise filters. ;o) 2. NOT filters can have false positives. An account could have the value set that you are trying to avoid but if the account trying to access the info doesn't have the access to see that value, it will be still be returned. This is why the extra useraccountcontrol=* in the filter. The list is sleeping, they should have been all over me on that dork up. eg Too late now Al, Dean and Deji Princess, don't worry I will explain it to you next time I see you. ;o) joe -- I am 78% Evil Genius I am pure evil. I lie awake at night devising schemes of world domination, and I will not rest until all living souls bend to my will. Take the Evil Genius Test at fuali.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, May 19, 2006 11:41 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OldCmp question Disabled accounts are marked by having bit 1 list on userAccountControl (value 2) To exclude them you want -af useraccountcontrol:AND:=2 and -bit I just realized I have an -onlydisabled switch, I should add a -onlynotdisabled I guess... -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Friday, May 19, 2006 11:25 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] OldCmp question Anyone know a way to easibly filter out disabled accounts from the oldcmp -users report? Would one have to use some sort of bitwise filter from a translation of a useraccountcontrol 66048 value or something? ~~ This e-mail is confidential, may contain proprietary information of Cameron and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ:
RE: [ActiveDir] [Exchange] Full Mailbox Directory Name holds wrong Administrative Group name
Victor, At first I was not sure what you were talking about. I've never used this column before (it's not displayed as one of the defaults and I'm used to looking at mailbox enabled accounts via cmdline and now PowerShell), but after looking atESM what you are really talking about (that most of us may be more familiar with) is the mailbox's legacyExchangeDN attribute (which is called "Full Mailbox Directory Name" in ESM). This attribute does not change when you move mailboxes from one server or administrative group to another, in fact changing this attribute's valuewill lead to messages that were send out by the moved mailbox not being replyable. So in a nutshell, there is absolutely nothing wrong with what you are seeing. It is expected and by design behavior. The legacyExchangeDN is used by Outlook clients (under the hood) to address and submit mail through MAPI. When anOutlookuser sends out an email to other internal mailboxes the from address, under the hood, is actually the legacyExchangeDN address (if viewed with a tool like MFCMapi it's the PR_SENDER_EMAIL_ADDRESS). So if you were to change this value then any messages sent out before the change would become unreplyable (ok, not 100% true, because you could add an X500 address to the user's mailbox-enabled account that matches the old legacyExchangeDN and then the messages would get properly delivered). Anyways, don't worry about it. There is nothing wrong and I would highly recommend leaving the "full mailbox directory name" alone. It's not that you can't change it, but you'd have to put it's old value in as an additional proxy address (of the X500 type) in order for mail to continue to be delivered properly. Don't really know what you'd gain from that in the end. Hope this helps explain it a bit. There is a lot more to it then that naturally, but I think the above summarizes some of the key points about why you would not want to change it. Best regards, Steven From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor W.Sent: Saturday, May 20, 2006 12:47 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] [Exchange] Full Mailbox Directory Name holds wrong Administrative Group name Still hoping for somebody to think with me on this matter :-( 75% of the mailboxes that were moved have a Full Mailbox Directory Name which has the Administrative Group in it from wich they were moved from, instead of the onethey are in now. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor W.Sent: donderdag 18 mei 2006 22:20To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] [Exchange] Full Mailbox Directory Name holds wrong Administrative Group name Perhaps I need to clarify this a little. What I mean is that a mailbox that has been moved to another Administrative Group, still has the Administrative Group in it's Full Mailbox Directory Name frow which it was moved. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor W.Sent: dinsdag 16 mei 2006 22:32To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] [Exchange] Full Mailbox Directory Name holds wrong Administrative Group name We are in the middle of a migration from Exchange 2000 to Exchange 2003. We have 2 Administrative Groups in ESM. one of them is named: First Administrative Group(this namewas left default at the time of the installation of the first server). The other has been given a new name.The First Administrative Group holds the Exchange 2000 servers, the other holds the Exchange 2003 servers. In the end only one Administrative Group will exist, the new one. Recently I moved a couple of hundred of mailboxes to a different server in a different Administrative Group. When looking at those mailboxes from withing ESM (by clicking the mailboxes node under the servers node), I can see that a mostof those mailboxes still have the name of the Administrative Group they were in, in their Full Mailbox Directory Name (this is a column that can be added in ESM). Themailboxes were on a server which was intheFirst Administrative Group and have been moved to another server which sits in another Administrative Group. I am asking this because when after all the mailboxes have been moved (a few are still on that old server), I am planning to delete the First AdministrativeGroup in time. My question is why does the Full Mailbox Directory Name still have the First Administrative Group in it, even if the mailbox is no longer in the First Administrative Group? Do I need to fix this before I will delete the First Administrative Group? Thanks in advance for the help.
RE: [ActiveDir] ADAM Schema Questions
Title: RE: ADAM Schema Questions 1) Off the cuff, Id speculate you hit init sync. If there is no partner and you have not replicated, FSMO roles will reject operations that leverage their FSMO-ness due to init sync requirements. The idea behind this was to stop old FSMO role holders to come back online and accept updates that conflict what other people have since performed if the FSMO role was seized while they were offline. Perhaps this is what you were hitting. ~Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, May 18, 2006 3:57 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM Schema Questions 1. What was the exact error you saw, with DSID? I have done schema mods of instances where one or more of the other instances were powered down so they couldn't replicate. 2. Which MMC app are you trying to hide it from? Could be a bug, but depending on the plugin, defunct attributes possibly should show up.It is up to the code to read the schema and determine the current state and then decide whether it should show the attribute or not. When you defunct something, the data behind the attribute is not purged. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernier, Brandon (.) Sent: Thursday, May 18, 2006 9:34 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM Schema Questions Please ignore part two of my question, I figured it out. I was only running dn: CN=MyClass,CN=Schema,CN=Configuration,DC=X changetype: modify replace: isDefunct isDefunct: TRUE - dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - As opposed to dn: CN=MyClass,CN=Schema,CN=Configuration,DC=X changetype: modify replace: isDefunct isDefunct: TRUE - dn: CN=MyClass,CN=Schema,CN=Configuration,DC=X changetype: modrdn newrdn: cn=MyClassOld deleteoldrdn: 1 dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - _ From: Bernier, Brandon (.) Sent: Wednesday, May 17, 2006 5:23 PM To: 'ActiveDir@mail.activedir.org' Subject: ADAM Schema Questions 1.) If you have a ton of server in a configuration set, when you do a schema extension and one box is down will it work? In my test I had two ADAM servers and it would not take the schema update because it couldnt replicate (I purposely broke replication with it's partner). 2.) When you defunct a class/attribute, whats the attribute to hide it from the MMC? I thought defunting it did hide it, but I am mistaken. Thanks! -Brandon
