Active Directory Archives

How-to keep a user synced with DirSync, to be excluded from DirSync while retaining the AD user

Converting DirSync User to a Cloud user in 365

I’m not sure if anyone has run into this problem before, so I figured I would share a quick fix that I found to take care of this problem. The easiest process that I have found to accomplish this without having the user be deleted each time dirsync runs is the following:

On a domain controller in the environment, move the user out of the DirSync scope. The Domain has a Synced and UnSynced OU, moving the user to the UnSynced OU accomplishes this.
Force replication on the DC a few times (unless there is only one DC in the environment)
Login to Office 365 and delete the user from Office 365- this will put them in a soft-deleted state.
From a DC in the users environment, run all of the DirSync/Azure AD Sync profiles to allow the changes to sync with 365
From Office 365 web portal, find the users mailbox in the Deleted Users section, select the appropriate user and re-attach the mailbox. You will need to specify a new password for the user to use when accessing Office 365 since they are no longer synced with AD.
Open up a PS-session to Office 365, Import the appropriate modules including MSOL modules
Run the following command substituting the appropriate value. The ImmutableID is what will prevent DirSync from deleting the user’s mailbox each time it is run. ImmutableID links the 365 account to the AD account and is what DirSync looks at to bind the two accounts (generally speaking).

Set-MSOLUser -UserPrincipalName %user@domain.com% -ImmutableID $null
From a DC in the user’s environment, run all of the DirSync/Azure AD Sync profiles to allow the changes to sync with 365
Validate that you can login via Office 365 with new password and that the account shows being in the cloud.

Good Luck!

Copy members from one Distribution Group to another Distribution Group in PowerShell

As an Exchange and Active Directory administrator you may be asked at some point to make a new distribution group from one or more other distribution groups. Exchange 2010 and PowerShell make this a very easy task. So to get started log in to your exchange server and open your Exchange Management Console.

exchangeManagementshell

Now we need to create the new distribution group by running the following command. Replace (GroupX) with the name of the group you want to create, replace the OrganizationalUnit with the location you want the group to show up in under Active Directory and change the SAM account name to your group name.

New-DistributionGroup -Name “GroupX” -OrganizationalUnit “cornetser.com/Users” -SamAccountName “GroupX” -Type “Distribution”

Next lets list out our existing Distribution Group to see who we will be coping to the new group.

Get-DistributionGroupMember “Florida”

Now we need to add the Distribution Group Members from “Florida” distribution group to the new GroupX distribution group.

Get-DistributionGroupMember “Florida” | Get-Mailbox | Add-DistributionGroupMember “GroupX”

To add more groups to the GroupX distribution groups rerun the same command as above with new group name to copy from in the “Get-DistributionGroupMember” section. Any duplicate members will error out as a duplicate and will be skipped as the list is copied so you will have a nice clean list once completed.

Enjoy,

Cubert 8)

[Solved] – Dcdiag fails for NCSecDesc test and adprep /rodcprep fails to fix it.

This was a real pain and we ended up having to call Microsoft and spend several hours to resolve what seem to be a simple issue. When running dcdiag you get an error that the NCSecDesc test failed with:

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have Replicating Directory Changes In Filtered Set access rights for the naming context: DC=cosgro,DC=com

Normally running adprep /rodcprep at the command line would correct the issues but in this case we kept getting the same response when running adprep.

Adprep detected the operation on partition DC=ForestDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=DomainDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=cosgro,DC=com has been performe d. Skipping to next partition. ============================================================================== Adprep completed without errors. All partitions are updated. See the ADPrep.log in directory C:\Windows\debug\adprep\logs\20130213141646 for more information.

And when we re ran DCDiag we would still get the same error. All the online documents say this should of resolved the issues but it had not.

The problem was not the ADPrep /rodcprep but the permissions were seen to be to “open” for the Enterprise Domain Controllers Group. The security permissions for this group was set to “full” on the main domain partition. This set of permissions needed to be more restrictive for the group. To fix we needed to open ADSI Edit and reset the permissions on the domain partition.

The picture below shows you where the domain partition resides, right click the partition and select properties.

Then on the pop up windows select the security tab. In the Groups and Users box find the “Enterprise Domain Controllers” group and then uncheck all permissions.

Now re-add only the list below to the allow column.

Manage replication topology
Replicating Directory Changes
Replicating Directory Changes All
Replicating Directory Changes In Filtered Set
Replication Synchronization

Apply the changes and rerun DCDiag to verify that the changes are working.

Thats it.

Enjoy Cubert 😎

How to fix NCSECDESC Failures in Active Directory after DCDiag reports a failure.

How to fix NCSECDESC Failures in Active Directory. If you get the following when running DCDiag on a Windows AD Server do the following to correct.

Starting test: NCSecDesc
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=ForestDnsZones,DC=MYDOMAIN,DC=local
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=DomainDnsZones,DC=MYDOMAIN,DC=local …………………….
MYHOST failed test NCSecDesc

Download fixfsmo.vbs and find or download ADPREP for your distribution of windows.

First run “cscript fixfsmo.vbs DC=DomainDnsZones,DC=MYDOMAIN,DC=local ” Change only the domain name to match domain, leave [DC=DOMAINDNSZONES]

Next run “cscript fixfsmo.vbs DC=ForestDnsZones,DC=MYDOMAIN,DC=local ” Change only the domain name to match domain, leave [DC=FORESTDNSZONES]

Next locate your ADPREP directory and change to\adprep, now run adprep /rodcprep . If you do not have the ADPREP tools you can get them from Microsoft’s website or on the original CD media your server came with.

Then rerun DCDiag to verify that the failures are gone.

Enjoy,

Cubert 😎

DCDiag fails with the host could not be resolved to an IP address check the DNS server, DHCP, server name, etc although the guid dns name couldn’t be resolved.

You run DCDiag and it returns a failure that names can not be resolved.

  
   testing server: default-first-site-name\mydomain
      starting test: connectivity
         the host 7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local could not be resolved to an
         ip address.  check the dns server, dhcp, server name, etc
         although the guid dns name
         (7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local) couldn't be
         resolved, the server name (myhost.mydomain.local) resolved to the ip
         address (192.168.1.5) and was pingable.  check that the ip address
         is registered correctly with the dns server. 
         ......................... myhost failed test connectivity

This is mainly due to bad or non existent DNS records on your AD server. Here are the steps to run through to make sure your Active Directory DNS has the correct records needed to allow Active Directory to function correctly in a Windows 2003 or Windows 2008 environment.

Steps to resolve:

Verify SRV Records
http://support.microsoft.com/kb/241515
SRV Records missing after Promo
http://support.microsoft.com/kb/241505
Verify All DC’s are point to one as “master”, Second to them self or another is better.
Verify DHCP Client Service is running (needed for Dynamic DNS updates)
Run at cmd prompt -> net stop netlogon && net start netlogon
Run at CMD prompt -> netdiag /fix
Re run at CMD prompt -> DCDiag.exe

You should now get a passing test when you run dcdiag.exe. You may see the following response to the dcdiag.exe execution.

Testing server: Default-First-Site-Name\MYDOMAIN
Starting test: Connectivity
*** Warning: could not confirm the identity of this server in
the directory versus the names returned by DNS servers.
If there are problems accessing this directory server then
you may need to check that this server is correctly registered
with DNS
……………………. MYHOST passed test Connectivity

Enjoy

Cubert 😎

[Kaseya Agent Procedure] Free Active Directory Health Monitor Script

Active Directory Health Monitor Script

From the skunk works here at Squidworks comes another great monitoring script for Kaseya.

The Active Directory Health Monitor Agent Procedure executes DCDiag on your Windows Active Directory server and captures any failures reported. The script then makes a unique event log entry into the Windows Application Event Log under the Application Events that can then be picked up by Kaseya’s Event Log Monitor. When Kaseya picks up this event you can instruct the monitor to create an alarm, create a ticket, run another agent procedure or email the alarm to an address(s). Just schedule the agent procedure to run a couple of times a day to keep an eye on your customers Active Directory health.

The script also provides a complete report of the DCDiag results in the event of a failure that you can view by going to the “Get Files” area of your host in Kaseya and under this folder will be an Active Directory folder where the DCDiag.txt file results are stored.

All files and a README are included in the ZIP. Feel free to POST here any issues or comments you may have.

Download -> Kaseya-ActiveDirectoryHealth

Enjoy

Cubert 😎

Quick and Easy Setup of Active Directory Authentication for VMware vSphere 5.1 SSO (Single Sign On)

VMware vSphere vCenter Server 5.1 now uses a new SSO (Single Sign On) service to authenticate with Microsoft Active Directory when deploying vCenter. If you do not install this services and configure it for AD then you will not be able to use your domain accounts with vCenter 5.1 During the initial install you may get errors when installing SSO. KB 2034374 reports that a error of ” Error 29155 Identity source discovery error” is due to a failed attempt to automatically discover your Active Directory domain. Verify that the domain name and DNS are setup correctly.

Now lets setup an AD server in vCenter to allow our Domain Accounts. First we will login to vCenter Web Client (https://127.0.0.1:9443) if you used the default ports for the web client installs. The default login is admin@system-domain and the password you set for SSO during the install process. Once you are logged in to the web client you can continue.

Now Select [Administration]

vCenter SSO-login

Now Select [Sign-On and Discovery] -> [Configuration]

SSO Configuration

Under the Identity Sources Tab in the right pane select the PLUS symbol to add a new AD source. This will pop up a “Add Identity Source” window, select the active directory radio button and fill out the requested information with you AD Domain name and the “OU” the holds your users and groups.

Here is the generic information you will need just replace the sesenviron.local with your domain and then place your AD credentials at the bottom.

Adding identity source

Now that we have a AD server assigned as a source we must now add this newly created connector to our “Default Domains ” list.

Add AD to Default Domains list

Now that we have it in our Default Domains list lets move it up to be our primary source. To do this highlight the AD domain name and select the blue arrow head pointing up and move the domain name to the top of the list .

Set priority of the domains

Now lets select the small floppy disk icon to save the changes to the default domain list box. Once this is complete we should be able to open up the vSphere client application and log in with domain access. You should be using a domain level admin to access vCenter.

I hope this helps some people out there.

Cubert 😎

How to Install Printers in Windows 7 WITHOUT Local Admin Rights

Microsoft made some changes to the network printing security in Windows 7 and as a result, many non-admin users are not able to install network printers with an Access Denied message.

I did some research on this today, and found a solution. We just need to make a new GPO on the domain level for each client network that is experiencing this problem. These are newer GPO extensions, so its best to create the GPO on a Windows Server 2008 R2 server. Otherwise, you’ll need to find the ADM extensions and install them on the Server 2003 system.

Configure Group Policy settings for “Point and Print” on BOTH computer and user settings (Vista previously only had user settings). The Location of the settings can be found here in GPOs:
1. Computer Configuration\Policies\Administrative Templates\Printers\Point and Print Restrictions
2. User Configuration\Policies\Administrative Templates\Control Panel\Printers\Point and Print Restrictions
You will need to specify all print servers on the network and be sure to disable all security prompts.

Enjoy,

Cubert 😎

Kaseya Agent Procedure -> Check Active Directory for Active User Changes

Agent Procedure “GetActiveADUsers” is a small script I created that grabs the list of all “active” users in all OU’s and pipes that information along with their email addresses to a file. The script then grabs file and stores that file in the GetFile Area inside Kaseya. The script is also setup to alarm on change which will allow you to add a monitor for “getfile” that will email you or do something when the list of users changes.

Makes a great tool when you have large AD environments where there are a lot of OU’s and/or users are scattered all over the AD infrastructure. The text file created provides the users full name, email address and dept name if filled out.

Get script here -> Procedure GetActiveADUsers

This is a zip file with the procedure XML file inside. You will need to assign this script to only Active Directory Servers and schedule it for once a day. Then select the Monitor Tab and then Alerts and create a Alarm using the “Get Files” option in the “Select Alert Function ” drop down list. Have it email you if the alarm is struck.

That’s all there is to it!

Enjoy Cubert 😎

[Solved] NTFRS – Journal Wrap Errors detected on Domain Controller

File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR

Are you getting this error in your File Replication Service?

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.
Replica set name is : “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)”
Replica root path is : “c:\windows\sysvol\domain”
Replica root volume is : \\.\C:
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.
[1] Volume “\\.\C:” has been formatted.
[2] The NTFS USN journal on volume “\\.\C:” has been deleted.
[3] The NTFS USN journal on volume “\\.\C:” has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on \\.\C:.
Setting the “Enable Journal Wrap Automatic Restore” registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.

This is caused when the Sysvol gets currupted and is simple to fix. I will walk you through the steps.

First off before we do anything lets backup by taking a Shadow Copy of the C: Drive. To do this we will open MyComputer and select the C:Drive, right click it and select properties. Now find the ShadowCopy Tab, highlight the C: Drive and click the “Create Now” button to create a backup point on the drive. You do not need to “Enable” ShadowCopy to take a 1 time snapshot.

Now that we have a backup point to go to if all hell breaks loose we can safely move on to the next step. Open up REGEDIT and navigate to the RegKey -> System\CurrentControlSet\Services\NtFrs\Parameters and create a new REG_DWORD key called Enable Journal Wrap Automatic Restore and place a 1 as the hex value.

Now launch a Command window(DOS) and run the following commands:

NET STOP NTFRS

NET START NTFRS

This will then cause the following to appear in your File Replication Service Event Log:

The File Replication Service is deleting this computer from the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” as an attempt to recover from the error state,
Error status = FrsErrorSuccess
At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

This will be followed by the following Event Log:

File Replication Service is scanning the data in the system volume. Computer MyDomainServer cannot become a domain controller until this process is complete. The system volume will then be shared as SYSVOL.

This will be followed by the following Event Log:

The File Replication Service moved the preexisting files in c:\windows\sysvol\domain to c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.

Now we need to wait a bit and allow the replication to complete. This has taken anywhere from 5 minutes to 20 minutes for me based on server and what is being replicated. You will know it is complete when you get the Event Log:

The File Replication Service is no longer preventing the computer MyDomainController from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.

Once you get this log your replication is complete and the Journal Wrap issues are fixed. We now need to go back to REGEDIT and change the entry we placed in there from a 1 to a 0.

You are all done.

May this help someone out there..

Cubert