Myrddin Emrys's questions

When reviewing some of our Windows servers, it can be extremely tedious to tell whether a security update is relevant to our system. A patch to IIS is irrelevant if we use Apache; an exploit affecting HTTP connections is not relevant if all our sites require HTTPS.

Identifying patches that are relevant or not to avoid unnecessary change to the system is very tedious. You need to click a link in every single update for More Info (which is even more fun when the server browser disallows all scripting on the destination page and Microsoft's own site breaks) because the patch summary is useless.

Is there a way to summarize the recommended update lists for a server (or client) that improves upon the poor summary Microsoft provides, so that a loading a separate browser page for every update is not necessary just to see what the update is for?

The use-case for this is quick, ad-hoc updates on individual servers, rather than organizational patch management.

I have a system that synchronizes from a master LDAP store. The synchronization process has gotten longer and longer as our directory grows. I had to stop syncing hourly, and moved it to an overnight schedule. But this results in more 'you have an account but I can't see it yet' problems.

I would like to add a parameter to the LDAP query that tells the system to only pull records modified in the past hour, and run it twice an hour; efficient and convenient. Unfortunately I can only find out how to filter on an absolute timestamp, such as (modifyDateStamp>=201311210000.u), but not a relative time. The system we are using cannot build a dynamically created query, so I can't generate a new UTC timestamp every time it runs.

The answers in this question only mention using the UTC time, so I am pessimistic. Is there a solution?

In a script, I need to manage the membership of a group. Unfortunately, the cmdlet for removing a member from a group, Remove-ADGroupMember is always asking for confirmation. This is contradictory to the described behavior of the cmdlet, as there is a -Confirm option that is supposed to turn on confirmation. This requires using obscure and poorly documented colon binding of a value to a switch parameter: -Confirm:$false, when it would make much more sense to instead use a straightforward -Force switch.

Is there a setting in the environment that is changing how the cmdlet behaves? Is this just a poorly implemented feature? Am I missing some obvious documentation that would explain the confusing behavior of switch parameters?

There is a strange and confusing (to me and to users) issue plaguing authentication. I do not know how long it has been occurring, but I believe it to be quite a while. Only recently, with the use of the Account Lockout tool have I realized that these authentication issues are sometimes caused by a glitch in the system rather than user error.

What happens is that a user authenticates correctly, but the system rejects their password. I wish to repeat: they log in with the correct username, password, and domain. This is not fat-fingering; it is not a client issue; it is not user error; it is not an expired password; it is not specific to any service.

The behavior when a user correctly authenticates is that the DC resets the ‘failed login’ count back to 0. When they fail, it increments it and sets the ‘last fail’ time. But when this glitch occurs, neither happens; the authentication attempt is rejected, but the count does not go up by 1, nor does it reset, and the last fail time does not change.

The issue occurs across multiple devices and services. Today I had a student fail to log in on multiple computers, as well as webmail. I compared the event logs from the computer and the DC; I con see no difference between the events when the user was wrongly rejected (and the failure count did not go up) and when she was correctly rejected because I had her mistype the password on purpose.

I have done this myself, attempting to log in to a student’s freshly created account (using a known password scheme). I have had it happen to users on many of the services that authenticate through AD. It has happened to staff, faculty and students. As far as I can tell, this is an authentication issue directly on the DCs; something wonky with the account, but not one of the typical culprits of expired password, disabled, etc.

Resetting the password fixes the issue. The problem just goes away. But the frequency of the issue (about 8-10 cases just this week, out of at most 100 network password resets) leads me to believe it is a serious problem.

I do not know how long this issue has been occurring. Without using the Account Lockout tool, I would never have seen that the error count was failing to increment, and thus assumed that the user was wrong about knowing the password. I have had many occurrences where users swore they knew their login, and it ‘worked yesterday’. I do not know how many of these times it was true, if ever. Even after getting the tool, it has taken multiple occurrences and several months of the issue occurring before I believed it was a real problem. Not till I actually had it happen to me, typing the student’s initial password, and seeing the failure count fail to rise, did I really believe it.

Our AD environment is mostly on Windows server 2008. Some DCs are still Server 2003. The environment is a single domain. If there are any other relevant technical details necessary for troubleshooting, please let me know.

Edit: As the accepted answer shows, it really was user error. The event that 'proved' to me that it was a real problem was when I logged in to a newly created account and it failed without incrementing the bad password count. We have standards for new accounts and what to reset passwords to. Likely another admin ignored the standard and reset this user's password to something else. When I attempted to log in to the new user, and the bad password failed to increment (yet I was rejected), I thought it was proof of an issue. Much Googling failed to find a page describing the situations under which the Bad Password Count fails to rise... hopefully this answer will help someone else in the future.

When we make changes and need to force an immediate synchronization, some significant annoyances have hindered us. The primary problem is that our DirSync server is pulling directory information from a tertiary DC that can be as much as half an hour out of date... sometimes. Other days it is using an appropriate DC. Since it is inconsistent we cannot use manual replication as a consistent workaround.

How can I configure the DirSync process to use a specific DC (or specific set of DCs) rather than allowing it to choose on its own? Barring that, is there a way to configure the entire computer to use a custom list of DCs (since the DirSync process inherits, I believe, the DC the server is using).

I moved a user's email account, and now cached x500 addresses to the user are failing. How do I translate the x500 in the bounce message to the correct x500 alias I should add to their mailbox?

Bounce text:

IMCEAEX-
_O=ORGANIZATION_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=John+20Doeb81@company.com

Matching x500 address:

/O=ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=John Doe

I am reasonably certain of the entire translation except that b81 near the end. However this translated x500 address (either with the b81 included or truncated) does not work for getting mail to properly arrive when I add it to the user. Is there documentation (or even better... a copy-paste translator page) on how to reverse engineer the correct x500 to add to the user so that cached account credentials continue to work?

The Exchange administration tools output the exact PS commands they will (or just did) execute. Is there a different version of the AD tools (primarily AD Users & Computers) that have similar functionality? If not, is this an expected feature of Windows 8 Server?

I'd like to be able to launch either the AD user dialog, or the EMC mailbox dialog directly from a Powershell script to open a specific user. The workflow goes something to the effect of "Does everything look correct on this user? Y/N" to continuing on, or to bringing up the account to edit.

There's no reason to completely duplicate the functionality of these dialogs. I don't mind requiring that EMC or ADU&C already be open before the script is run, if necessary.

I have recently been doing a lot of updates to our network drive permissions... such as consolidating direct user permissions into group permissions. The built-in ACL editor (Advanced Security Settings dialog) is adequate, but its limitations are frustrating, particularly that it cannot be resized and you cannot look at the list of existing entries at the same time as you are adding a new entry.

Is there an improved ACL editor that can be downloaded to supplement the default one?

I should first note that we have nobody in IT with significant familiarity with self-signed certification. We have a moderately sprawling network (one forest, many locations), and we are now rolling out internal code signing; until now users have run untrusted code, or we even disabled(!) the warnings. Intranet applications, scripts, and sites will now be signed with self certification.

I am aware of two obvious ways we can deploy this: Distributing the keys directly via a group policy, and setting up a cert server. Can someone explain the trade-offs between these two methods? How many certs before the group policy method is unwieldy? Are they large enough that remote users will have issues? Does the group policy method distribute duplicates on every login? Is there a better method I am not aware of?

I can find a lot of documentation on certifications and various ways to create them, but I have not been able to find something that summarizes the difference between the distribution methods and what criteria make one or the other superior.

I have an AD: drive, which should allow me to browse active directory from within Powershell. But when I try to use it, it will not let me navigate beyond the root. From what I have read the given commands should work, but they are failing.

PS AD:\> ls

Name                 ObjectClass          DistinguishedName
----                 -----------          -----------------
company              domainDNS            DC=company,DC=com
Configuration        configuration        CN=Configuration,DC=company,DC=com
Schema               dMD                  CN=Schema,CN=Configuration,DC=company,DC=com
ForestDnsZones       domainDNS            DC=ForestDnsZones,DC=company,DC=com
DomainDnsZones       domainDNS            DC=DomainDnsZones,DC=company,DC=com

PS AD:\> cd schema
Set-Location : Cannot find path 'AD:\schema' because it does not exist.
At line:1 char:3
+ cd <<<<  schema
    + CategoryInfo          : ObjectNotFound: (AD:\schema:String) [Set-Location], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

PS AD:\> cd Schema
Set-Location : Cannot find path 'AD:\Schema' because it does not exist.
(duplicate of previous error)

PS AD:\> cd company
Set-Location : Cannot find path 'AD:\company' because it does not exist.
(duplicate of previous error)

PS AD:\> ls Schema
Get-ChildItem : Cannot find path '//RootDSE/Schema' because it does not exist.
(duplicate of previous error)

PS AD:\> cd ForestDnsZones
Set-Location : Cannot find path 'AD:\ForestDnsZones' because it does not exist.
(duplicate of previous error)

We are migrating from Exchange 2003 with no quota settings to Exchange 2010 with limited mailbox sizes. We are trying to get users to clean their mailboxes prior to the move to reduce the transfer load, as well as to comply with new quotas on the 2010 system.

But many users access their mail through webmail only. I cannot see a way for users to access their mail store size in this manner.

Has anyone else run into this problem? Is there a good way to easily let users check their own mailbox size? The only thing I've come up with as a workaround is a report that IT generates and mail-merge it out to users daily with their current mailbox size. This is cumbersome and time consuming compared to a way for them to check their own mailbox size however.

Client filtering in Outlook 2010 is disabled when the server is managing spam filtering. Unfortunately I have a few high profile users that prefer to spam-block mailing lists rather than unsubscribe, so even though the email is not really spam they are upset that it is coming into their mailbox.

As seen here, I am not the first person to wrestle with this issue, and the suggested fix there (setting New-FseExtendedOption –Name CFAllowBlockedSenders –Value true) also failed to work for me.

Can anyone provide another possible fix? Thank you kindly.

I have a network share folder that I was recently cleaning up permissions to. I took off the four individual names from the access permissions to the folder, and added a new security group (Universal) with standard Read/Write permissions to that folder, then added those 4 people to the group.

However... now nobody can see the folder. The users can see the other 9 folders in that shared drive, but the 10th is missing. I cannot see any security permission in the parent folder or in the folder itself which would cause it to be invisible to anyone, regardless of whether they have permission to open it or edit files within.

Edit: The file server (unlike the Exchange and DC) is Server 2008. Apologies for the incorrect information previously, I had not actually remoted into the file server directly before. However, for the share in question Access Based Enumeration is disabled.

Edit 2: As noted in a comment below, ABE was enabled. Confusingly, someone set up the shared area for the site using nested shares... \server\share\shareA\folders. While 'share' did not have ABE enabled, 'shareA' did. My lack of in-depth knowledge of the configuration delayed accurate diagnosis of the issue.

I can't seem to find a way to run the various Exchange tasks (Establish E-mail Address, Remove Exchange Attributes, Create Mailbox, etc) from Powershell. It seems unlikely to me that Exchange tasks are not possible to automate; does someone have a starting point for me to automate repetetive Exchange tasks?

PowerShell would be the preferred language, but if there is no way but via .NET or similar I could go that route.

In my organization, we have a corporate domain (company.com) and child domains (sub.company.com). Our child domains have their own exchange servers. This server happens to be Exchange 2003.

One of them has an annoying problem. Most accounts are created by script (and work fine), but when we create an account manually (via AD Users & Computers) the email address is entered incorrectly. Rather than giving the new mailbox '[email protected]', it assigns them '[email protected]'.

When creating a user with a mailbox there is a 1 to 3 minute delay, which is normal. However, this makes it a royal pain to create accounts properly, as you have to wait the minute or three before you can go in and fix the email address (as simple as renaming it under the E-mail Addresses tab).

Where is the setting for the server that determines the default domain for a new email address? Somewhere we messed it up, and though it is not a serious issue (since mail delivery works, and most accounts are created via script), it's a frustration that grates on me, especially when I forget to check back and a user is upset a week later because they still can't get email.

I would like to manage my distribution lists indirectly, via security group. So that when I add a user to the appropriate security groups, they will automatically be members of the appropriate distribution groups.

Distribution Group Everyone ([email protected])
  Security Group A
    User 1 ([email protected])
    User 2 ([email protected])
  Security Group B
    User 3 ([email protected])
    User 4 ([email protected])

The security groups are not (and I would prefer that they remain not) mail enabled. Is this a viable setup? Is there something special I need to do to have this work? On the surface, it appears to be failing, so I suspect I must make the security groups mail enabled, but it frustrates me that there is not a better solution.

The problem is that I do not want users to get into the habit of emailing security groups directly, and if I mail-enable them then expanding the distribution group will result in them seeing the child groups, and possibly using them instead of the distribution list. Similar to an unpublished API, having this information visible may come back to haunt me at some future point.