If You Experience Something Like ...

DHCP Server on Windows Server 2012 R2

In this post I'll write about error (warning) events I have experienced during replacement of DHCP server from Windows Server 2003 to Windows Server 2012 R2.

For DHCP database migration I was using netsh dhcp server export (import) option. Running Netsh dhcp server import command on Windows Server 2012 R2 has added the running command user account into HKLM\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl which produced Warning Events into Application Event log from VSS source with event id 8230:

Log Name:      Application
Source:        VSS
Date:          Date
Event ID:      8230
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Computer Name
Description:
Volume Shadow Copy Service error: Failed resolving account account name with status 1376. Check connection to domain controller and VssAccessControl registry key.

Deleting this user account from HKLM\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl has resolved these warning events, and these warning events were not logged into application event log any more.

Another issue during this DCHP replacement "project" is that during installation of DHCP role, the installation process will change permissions on following registry key HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag . This registry key has block inheritance enabled and before installation of DHCP service role SDDL for this registry key looks like this:

Sddl : O:SYG:SYD:PAI(A;CIIO;RC;;;OW)(A;;KA;;;SY)(A;CIIO;GA;;;SY)(A;;CCDCLCSWRPSDRC;;;LS)(A;CIIO;GA;;;LS)(A;CIIO;GA;;;NS
)(A;;CCDCLCSWRPSDRC;;;NS)(A;;KA;;;BA)(A;CIIO;GA;;;BA)(A;;KR;;;BU)(A;CIIO;GR;;;BU)(A;CIIO;GA;;;BO)(A;;CCDCLCSWRPS
DRC;;;BO)

From D part of the sddl string D:PAI can be confirmed that block inheritance is enabled, and also Network Service has permission on this registry key from following entries (A;CIIO;GA;;;NS)(A;;CCDCLCSWRPSDRC;;;NS).

After DHCP role installation in permission entries for HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag, permission for DHCP server can be found represented as (A;CI;CCDCLCSW;;;S-1-5-80-3273805168-4048181553-3172130058-210131473-390205191). Also, the other permissions are not the same as before, but are inherited from the parent HKLM\SYSTEM\CurrentControlSet\Services\VSS, and the sddl now look like this:

Sddl : O:SYG:SYD:AI(A;CI;CCDCLCSW;;;S-1-5-80-3273805168-4048181553-3172130058-210131473-390205191)(A;ID;KR;;;AU)(A;CIIOID;GR;;;AU)(A;ID;CCDCLCSWRPSDRC;;;SO)(A;CIIOID;SDGWGR;;;SO)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)

From D part of the sddl (D:AI) can be confirmed that permissions are inherited, and Network Service does not have any permission. This situation will result in generating error event with id 8193 from VSS source in Application event log:

Log Name:      Application
Source:        VSS
Date:          Date
Event ID:      8193
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      computer name
Description:
Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...). hr = 0x80070005, Access is denied.

This behavior was also noted with Windows Server 2008 R2 and published in following Microsoft article http://support.microsoft.com/kb/2298620 .
In order to resolve this situation I've delegated Network Service permissions as were before installation of DHCP server role, and the error event 8193 from VSS was not logged any more.
Here is GUI overview of the Network Service permissions for HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag:

For more info about sddl check MSDN https://msdn.microsoft.com/en-us/library/aa379567(v=vs.85).aspx .

Windows 10 media briefing Jan 2015

Microsoft has announced Windows 10 media briefing for January 21, 2015 9:00AM PT or 6:00PM CET. Next preview version of Windows 10 should be available soon after the event.
For more info about this event check Windows Blog or http://news.microsoft.com/windows10story/

How to find out all locked out accounts in Active Directory using Powershell

This one liner PowerShell for reference, is intended to show how to find out all locked out accounts in Active Directory using Search-ADAccount with LockedOut parameter (ActiveDirectory module is required):

Search-ADAccount -LockedOut

The output from this cmdlet will list all the locked out accounts. Furthermore, if you want to unlock all those accounts, the output of the Search-ADAccount can be piped to Unlock-ADAccount cmdlet (permission for unlocking ad accounts is required) for example:

Search-ADAccount -LockedOut | Unlock-ADAccount

For more info about these powerful cmdlets please check TechNet: Search-ADAccount and Unlock-ADAccount .

Warning Event 9327 from MSExchangeSA

In this case Warning Event 9327 from source: MSExchangeSA was logged in Application Event log on Exchange 2010 server responsible for OAB generation by default every day on 5 AM:

Log Name:      Application
Source:        MSExchangeSA
Date:          12/1/2014 5:04:50 AM
Event ID:      9327
Task Category: (13)
Level:         Warning
Keywords:      Classic
User:          N/A
Description:
OALGen skipped some entries in the offline address list '\Global Address List'. To see which entries are affected, event logging for the OAL Generator must be set to at least medium.
- \Default Offline Address List

By default, event logging for the OAL Generator is set to lowest level. In order to see why some entries are skipped by OAL Generator, event logging level must be set to at least medium. One way to set this requirement is by using PowerShell :

Set-EventLogLevel -Identity "ExchangeServerName\msexchangesa\oal generator" -Level Medium

Setting the logging level to Medium for the OAL generator will produce a lot of events during the generation of OAB. Informational events generated from MSExchangeSA with Event ID 9359 can be safely ignored, but error events with id 9325 are the one that are triggering the event id 9327 from MSExchangeSA. For example:

Log Name:      Application
Source:        MSExchangeSA
Date:          12/25/2014 5:04:03 AM
Event ID:      9325
Task Category: (13)
Level:         Error
Keywords:      Classic
User:          N/A
Description:
OABGen will skip user entry 'John Doe' in address list '\Global Address List' because the SMTP address '' is invalid.
- \Default Offline Address List

John Doe was not having email address, but was having "ShowInAddressBook" property populated. So, in order to fix this behavior, I've created mailbox for this user, and after that immediately disabled the mailbox for this user, and all exchange related properties were cleared from this user.

Now, return (set) the event logging level for the OAL generator to default (lowest) value:

Set-EventLogLevel -Identity "ExchangeServerName\msexchangesa\oal generator" -Level Lowest

And, warning Event 9327 from source: MSExchangeSA was not logged in Application Event log on Exchange 2010 server responsible for OAB generation in 5 AM.

Setting calendar permissions in Exchange 2010

This is quick post for reference, and is intended to show how to manage user's calendar permissions in Exchange 2010. Four PowerShell cmdlets are available for achieving this task:

For example:

To list (get) assigned calendar permissions on user Jane.Doe here is the syntax:

Get-MailboxFoderPermission -identity jane.doe:\calendar

To assign John.Doe Reviewer permission on Jane.Doe calendar (John does not have any permission on Jane's calendar):

Add-MailboxFolderPermission -identity jane.doe:\calendar -user "John Doe" -AccessRights Reviewer

To modify already assigned permission to John Doe on Jane Doe calendar from Reviewer to Editor:

Set-MailboxFolderPermission -identity jane.doe:\calendar -user "John Doe" -AccessRights Editor

And finally to remove already added permission for John Doe on Jane Doe calendar:

Remove-MailboxFolderPermission -identity jane.doe:\calendar -user "John Doe"