Tag Archives: Active Directory

Bulk update emails in AD

9 Jan

Numerous ways to do this however perhaps the easiest is open Active Directory Users and Computers, select the users you want to update, get their properties, and Email to the variable field you have already used, %username%@restofaddress. ADUC will flesh out the username for you. You’re not restricted to the domain name AD uses, it’s a free-form field.

Advertisements

Recover deleted AD Object

31 Jan

Original Microsoft Tech Net guide

 

OLD WAY!https://technet.microsoft.com/en-us/library/dd379509(v=ws.10).aspx

 

NEW WAY!

 

How to Restore a Microsoft Server 2012 Active Directory Object from the Active Directory Recycle Bin

  • Last updated on Oct 26, 2016

This article refers to the Barracuda Backup Legacy Release firmware or newer, and Microsoft® Active Directory (AD) on Microsoft Windows Server® 2012. For information on backing up the AD, refer to How to Back Up Microsoft Active Directory.

Before attempting to recover a domain controller, first review the Microsoft TechNet article Domain Controller Recovery[1] for a complete list of recommendations.

Use the following steps to restore an AD Object from the AD Recycle Bin:

  1. Log in to the Windows Server 2012 as the administrator.
  2. Go to Start, and type dsac.exe to open the ADAC, or in Server Manager, click Tools, and then click Active Directory Administrative Center.
  3. In the left pane, click on the target Server name; a Deleted Objects container displays in the center pane:
    ad_server2012.png

    Deleted Objects Container
    If the Deleted Objects container does not display, right-click on the Server name in the left pane to enable the container.

  4. Double-click the Deleted Objects container to view a list of deleted items which can be restored.
  5. Right-click on the user to restore, and click Restore:
    restore_ad.png
  6. Verify the user has been restored.

 

 

 

Papercut and AD

20 Apr

Good read if you are new to Papercut and AD

.local to Office365 SSO

18 Apr

How to prepare a non-routable domain (such as .local domain) for directory synchronization


APPLIES TO: Office 365 Admin
When you synchronize your on-premises directory with Office 365 you have to have a verified domain in Azure Active Directory. Only the User Principal Names (UPN) that are associated with the on-premises domain are synchronized. However, any UPN that contains an non-routable domain, for example .local (like billa@contoso.local), will be synchronized to an .onmicrosoft.com domain (like billa@contoso.onmicrosoft.com). If you currently use a .local domain for your user accounts in Active Directory it’s recommended that you change them to use a verified domain (like billa@contoso.com) in order to properly sync with your Office 365 domain.

What if I only have a .local on-premises domain?

The most recent tool you can use for synchronizing your Active Directory to Azure Active Directory is named Azure AD Connect. For more information, see Integrating your on-premises identities with Azure Active Directory.

Azure AD Connect synchronizes your users’ UPN and password so that users can sign in with the same credentials they use on-premises. However, Azure AD Connect only synchronizes users to domains that are verified by Office 365. This means that the domain also is verified by Azure Active Directory because Office 365 identities are managed by Azure Active Directory. In other words, the domain has to be a valid Internet domain (for example, .com, .org, .net, .us, etc.). If your internal Active Directory only uses a non-routable domain (for example, .local), this can’t possibly match the verified domain you have on Office 365. You can fix this issue by either changing your primary domain in your on premises Active Directory, or by adding one or more UPN suffixes.

Change your primary domain

Change your primary domain to a domain you have verified in Office 365, for example, contoso.com. Every user that has the domain contoso.local is then updated to contoso.com. For instructions, see How Domain Rename Works. This is a very involved process, however, and an easier solution is to add UPN suffixes, as shown in the following section.

Add UPN suffixes and update your users to them

You can solve the .local problem by registering new UPN suffix or suffixes in Active Directory to match the domain (or domains) you verified in Office 365. After you register the new suffix, you update the user UPNs to replace the .local with the new domain name for example so that a user account looks like billa@contoso.com.

After you have updated the UPNs to use the verified domain, you are ready to synchronize your on-premises Active Directory with Office 365.

Step 1: Add the new UPN suffix

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Domains and Trusts.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Domain.msc, and then choose OK.

    Choose Active Directory Domains and Trusts.

  2. On the Active Directory Domains and Trusts window, right-click Active Directory Domains and Trusts, and then choose Properties.

    Right-click ActiveDirectory Domains and Trusts and choose Properties

  3. On the UPN Suffixes tab, in the Alternative UPN Suffixes box, type your new UPN suffix or suffixes, and then choose Add > Apply.

    Add an new UPN suffixChoose OK when you’re done adding suffixes.

Step 2: Change the UPN suffix for existing users

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Active Directory Users and Computers.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Dsa.msc, and then click OK

  2. Select a user, right-click, and then choose Properties.
  3. On the Account tab, in the UPN suffix drop-down list, choose the new UPN suffix, and then choose OK.

    Add new UPN suffix for a user

  4. Complete these steps for every user.

    Alternately you can bulk update the UPN suffixes by using PowerShell.

You can also use Windows PowerShell to change the UPN suffix for all users

If you have a lot of users to update, it is easier to use Windows PowerShell. The following example uses the cmdlets Get-ADUser and Set-ADUser to change all contoso.local suffixes to contoso.com.

See Active Directory Windows PowerShell module to learn more about using Windows PowerShell in Active Directory.

  • Run the following Windows PowerShell commands to update all contoso.local suffixes to contoso.com:
    $LocalUsers = Get-ADUser -Filter {UserPrincipalName -like *contoso.local'} -Properties userPrincipalName -ResultSize $null
    $LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("contoso.local","contoso.com") $_ | Set-ADUser -UserPrincipalName $newUpn}

DNS Configuration on DC

7 Oct
How we should Configuere DNS on our DC :–>

Every DNS server should Point to its own IP as a primary DNS and DNS located in remote site as a secondary DNS in

TCP/IP properties
All the unused NIC’s to be disabled
Valid DNS Ip from ISP to be configuered in DNS forwarders Do not configuere local DNS in forwarders
Public DNS IP’s Should not be used at any NIC Card except Forwarders
Domain Controllers should not be multi-homed
Running VPN server and RRas server makes the DC multihomed refer

http://support.microsoft.com/default.aspx?scid=kb;en-us;272294

If anything above is incorrect please correct it and run “ipconfig /flushdns & ipconfig /registerdns ” and restart

DNS service using “net stop dns & net start dns”

DNS best practices
http://technet.microsoft.com/en-us/library/cc778439(v=WS.10).aspx

Checklist: Deploying DNS for Active Directory
http://technet.microsoft.com/en-us/library/cc757116(v=ws.10)

Also some further discussion on the issue can be found here