• Main
  • Blog
  • Who We Are
    • Jeremy Anderson
    • Amy Babinchak
    • Steve Banks
    • Cliff Galiher
    • Brian Higgins
    • Eriq Neale
    • Edwin Sarmiento
    • David Shackelford
  • Store
    • Webinar Archives
  • Support
  • Forum
  • FAQ
  • My Third Tier
  • Datto

Archive for Active Directory

Feb
1

How do Rejoin a Computer to the Domain without Losing it’s SID

by amy

Post to Twitter Post to Facebook Post to StumbleUpon

This trick comes to be via my Active Directory study group. I suggest that everyone join a usergroup and/or a study group. It’s not that we don’t know AD, it’s that we forget or miss new features. A refresher course is fun too.

Occasionally a computer will come “disjoined” from the domain. The symptoms can be that the computer can’t login when connected to the network, message that the computer account has expired, the domain certificate is invalid, etc. These all stem from the same problem and that is that the secure channel between the computer and domain is hosed. (that’s a technical term. Smile )

The classic way to fix this problem is to unjoin and rejoin the domain. Doing so is kind of a pain because it requires a couple of reboots and the user profile isn’t always reconnected. Ewe. Further if you had that computer in any groups or assigned specific permissions to it those are gone because now your computer has a new SID, so the AD doesn’t see it as the same machine anymore. You’ll have to recreate all of that stuff from the excellent documentation that you’ve been keeping. Uh, huh, your excellent documentation. Double Ewe.

Instead of doing that we can just reset the secure channel. There are a couple of ways do this:

  1. In AD right click the computer and select Reset Account. Then re-join without un-joining the computer to the domain. Reboot required.
  2. In an elevated command prompt type: dsmod computer “Computer DN” – reset. Then re-join without un-joining the computer to the domain. Reboot required.
  3. In an elevated command prompt type: netdom reset MachineName /domain DomainName /User0 UserName /Password0 {Password | *} The account whose credentials you provided must be a member of the local administrators group. No rejoin. No reboot.
  4. In an elevate command prompt type: nltest /Server:ServerName /SC_Reset:Domain\DomainController  No rejoin. No reboot.
0 Categories : Active Directory, Amy Babinchak
Jan
25

Active Directory Best Practices: Accidental Deletion and Container Redirection

by amy

Post to Twitter Post to Facebook Post to StumbleUpon

My usergroup has an Active Directory study group going of which I am a member. Each week we review a chapter in the wonderful “Configuring Windows Server 2008 Active Directory 2nd Edition” self-paced training kit. The authors have done a fantastic job. All the members of the group are experienced long time IT professionals. We have 3 consultants, 2 internal IT and 1 looking for an internal IT position as members. We all have many years experience but decided that a refresher course was a good idea. Sure we all know how to use the basics in AD but we have probably missed some Best Practices, Tips and Tricks along the way. We’ve probably also forgotten some things that we knew but didn’t use often enough. This is the reason for the study group and all of the above has been absolutely true. It’s been fun as well, since we all have years of experience we bring those examples to the table and it makes for great geek conversation.

Here are a couple of the items that have made my Best Practices list so far:

Protecting from Accidental Deletion Now here is an under the radar item that is going to prove very useful. You can now protect OU’s, Containers, Groups and Objects from accidental deletion. It is as simple as a checkbox and for most new items in AD the box is checked by default. But for existing items it is not. You’ll need to go in and retro fit those with protection.

image

If you have a big complex AD then you can use PowerShell to fit the whole thing with this protection. But what is that Check box actually doing? It is changing the ACE permissions on the object. When that box is checked an ACE is added to Deny Everyone group Delete and Delete Subtree.

This isn’t the kind of thing that you’ll find yourself needing often (I hope) but now that you’ve read this, if you don’t go and set that check box you’ll kick yourself later.

Redirecting the Default Computer and User Containers New computers and users being left in the Computers and Users containers for long periods of time has long been one of my pet peeves. It distresses me that no one notice that this person or computer has not been subject to Group Policy, as the rest of the domain is. So when I found this little gem, it made my day.

The commands are: RedirCmp and RedirUsr to redirect anything that lands in the Computers container and the Users container respectively.

The command is entered in an elevated command prompt like this: redircmp “DN of OU for new computer objects”  So simple!  But you do need to be careful. Take a look at the Computers containers after you do this, there is no reference that it’s been redirected. Therefore, TODO make a note in the description of the container to remind you and future IT admins that this container is redirected and to where.

I have a few more items that have made my BP list but I’ll save those for another post. Keep reading!

0 Categories : Active Directory, Amy Babinchak
Aug
8

Return of the Brain Explosion: Mastering Remote Access

by amy

Post to Twitter Post to Facebook Post to StumbleUpon

Join us on September 29th in Las Vegas as we gear up for the SMB Nation conference with a Masters Class in Implementing and Supporting Remote Access brought to you by members of our staff.

Last year we had a ball, training all day and freely pouring beer into the night. A true geek festival. We’re going to do it all over again. Since last year there’s been a dramatic proliferation of demand for remote access by your users. During this pre-day event we’re going to deep dive into the stuff that makes remote access to network resources reliable, secure and functional for your end users. When you implement this stuff you’ll be the hero! All the content is going to be delivered by Third Tier staff. This is your chance to pick their brains in person. Speakers include: Brian Higgins, Jeremy Anderson, Steve Banks, Amy Babinchak, Cliff Galiher and David Shackelford. That’s a lot of big brains for one room!

Space is limited. Last year we sold out! Registration is about to open. So save the date and keep an eye on this blog.

Here’s what we’re going to cover:

8:30am – doors open, meet & greet, welcome

9:00am – The day begins with DNS. A fitting start to a day full of understanding remote access technologies. DNS is the foundation to all network communications and we’ll show you how the packets flow, which DNS entries are critical and how to create them.

10:15 – break (15 min)

10:30 – So now you’ve got your DNS records in place and understand which remote access technologies require which kinds of records. This bring us to security. In this session we’ll demonstrate how to secure VPN remote access using Radius. You’ve seen that Radius option in your router, in your firewall and even in your server. So why aren’t you using it to secure remote access to your network? We’ll show you how it’s done.

12:00 – lunch break (30 min) Vendors Lunch.

1:00 – Remote Web Access is a very popular feature of Small Business Server. In this session we’re going to tear it down bit by bit and show you exactly how it works. There’s no OZ behind the curtain. Instead there’s built-in Windows technology. Leave from this session not only able to troubleshoot RWA but also able to create an RWA like interface for your non-SBS domains.

2:30 – break (15 min)

2:45 – Tablets, netbooks, iPads, Smart Phones, Apple, Microsoft, Android these devices are everywhere! Which apps can really empower your end users? Which apps are secure and can you make them more secure? In this session we’ll demo a bunch of stuff that it working in the real world for real clients.

4:15 – Final thoughts, dismiss

Later that same evening: PARTY with Third Tier at the local Pub.

0 Categories : Active Directory, Amy Babinchak, Brain Explosion, Brian Higgins, Cliff Galiher, Dave Shackelford, Jeremy, Networking, SBS 2011, SMB Nation, Steve
Nov
19

Complications from an SBS 2008 Migration

by amy

Post to Twitter Post to Facebook Post to StumbleUpon

We ran across an interesting complication during an SBS 2003 to SBS 2008 migration. We run extensive checks on our SBS 2003 servers before performing migrations and this has always served us well. You may have even heard me talk on the various tasks we undertake and tests that we run. In this case we had a local client with an SBS 2003 server that we did not install. Further the previous hardware had failed causing the server to shutdown abruptly over and over again and we had imaged this SBS 2003 server onto new hardware about a year prior. Everything seemed fine with it though and the previous year had gone smoothly with this server.

We fully patched it. We defragmented the Exchange database. We ran the BPA. We updated the NIC drivers. We fixed up a journal wrap problem. We ran dcdiag to test DNS-AD integration. We ran gpupdate. We ran repadmin to test AD sync. We ran the BPA again and it told us that the server held none of the FSMO roles. !***!&*($&#*(&$*!!!!! Yikes. We verified all of them in the GUI. We verified all them using command prompt tools and it came back as holding all of the FSMO roles. Still the BPA persisted in claiming that it did not, so we postponed the migration while we gathered our thoughts. After consulting with everyone we could think of that was an expert in AD, it was concluded that if the AD itself knew that the server held the roles and all of the usual tests came back good that the BPA must be on drugs. The migration was scheduled.

We took a backup. We took an image. We mounted the image onto our virtual server. We started and finished the migration. We migrated the mailboxes, moved the data and generally progressed through the to do list smoothly. Then we noticed the event log in the SBS 2003 server. It said that a recent DC Promo was unable to complete and AD replication was halted until it finished. Sure enough when we tried to add a user as a test, the user did not sync between the servers. AD was not replicating. Testing AD pointed to a problem with the objects in the Computer OU and DNS-AD integration tests said that it was unable to find the PDC. It claimed records were missing that were not missing. Rather than turn back to an SBS 2003 server that no one was able to determine why the BPA said didn’t hold the FSMO roles, we decided our options were to press forward to try to fix the AD or create a new domain. Since everything was working, from the user perspective, we decided we had a bit of time to work on fixing AD before our 21 day migration period was up. Work began.

Moving forward with the migration we got to the point were we decided to uninstall Exchange 2003 and attempt a demotion of the SBS 2003 server. The uninstall of Exchange 2003 went along fine. However when we tried to demote the SBS 2003 server it informed us it thought it was the last replication of DNS in active directory. Hard stop.

To troubleshoot Active Directory we checked schema version on both the server and found it was set to 44. Good but we needed them to replicate with each other. So, we deleted the connection objects on both of the servers. Went into DSSITE on both servers and told it to check replication topology.  Waited for some time and we got the connection object back. We forced replication and it was successful! Problem solved.

We thought, problem solved. Shortly thereafter we got a call from the client, Outlook was reporting Disconnected. A look at Exchange 2007 showed that all of the mailboxes were gone! But the good news was that the mailbox store was still the right size so we knew that they were in there. We just needed to connect to them. Exchange Command shell: get-mailboxdatabase |clean-mailboxdatabase  to have all disconnect mailboxes show up in the Console then in the console, go to disconnectted mailbox, right click each mailbox and choose connect.  Do this for each users mailbox and another problem solved.

Are we done yet? No, yet another issue reared it’s ugly head. Users with large mailboxes were getting a message that their mailbox was too big and they were blocked from sending or receiving email. <sigh> Look at the Mailbox size limitation in the SBS Console and it still held our settings to allows for larger mailboxes for the Standard User Role. Reapply the role. No change. Back into the Exchange Management Console we go. Here we set the mailbox size for the users directly.

No further problems have presented themselves so we believe that we have successfully migrated an SBS 2003 with AD problems over to SBS 2008. Overall it was a good learning experience for the technician involved and now we know that the BPA is never on drugs. Apparently it knows things about AD that AD doesn’t even know about itself.

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Third Tier Get Support BlogFeed Blog Twitter Twitter Facebook Facebook LinkedIn LinkedIN

1 Categories : Active Directory, Amy Babinchak, Exchange, Migration, SBS 2008

Search

Support

Third Tier provides advanced support services to IT Professionals. Learn about what we do at http://www.thirdtier.net or click on the support icon below to chat with one of our support representatives.

Third Tier
Copyright © 2012 All Rights Reserved
iThemes Builder by iThemes
Powered by WordPress