News Categories
Announcement (9) Amy Babinchak (64) Tips (1) SBS 2011 (6) Windows Essentials 2012 (4) Edwin Sarmiento (28) SQL Server (22) SQL Server 2012 (6) SQL Server Clustering (3) SQL Server Disaster Recovery (6) Windows Server 2008 Clustering (1) log shipping (1) Brian Higgins (3) Uncategorized (42) Hyper-V (67) Virtualization (13) Windows 8 (13) Cisco VPN Client (1) Windows Server 2012 (24) Friend of TT (4) Hangout (2) Office365 (4) DNS (8) Jeremy (7) Cliff Galiher (3) Active Directory (12) ClearOS (4) Linux (4) presentations (2) SQL PASS (6) Chris Matthews (4) Printers (2) SharePoint (8) SQL Server Administration (7) Windows PowerShell (3) recovery model (1) sql server databases (1) Dave Shackelford (7) SMB Nation (1) Steve (1) Boon Tee (5) Kevin Royalty (3) Lee Wilbur (2) Philip Elder (10) SMBKitchen Crew (31) Susan Bradley (15) AlwaysOn (1) AlwaysOn Availability Groups (4) readable secondaries (1) row versioning (1) undocumented (1) The Project (2) Webinar (3) Enterprise for SMB Project (9) Security (25) Remote Desktop Connection for Mac (1) Remote Desktop Services (8) Windows Server 2008 (1) Exchange (15) Powershell (6) Microsoft (15) Performance (7) data types (1) Server 2012 (1) monitoring (1) DevTeach (1) SQL Server High Availability and Disaster Recovery (5) Clusters (44) Hyper-V Server 2012 (2) Business Principles (26) Cost of Doing Business (13) DHCP (7) sbs (15) Windows Server (30) SMBKitchen (26) Windows Server 2008 R2 (4) StorageCraft (1) P2V (1) ShadowProtect (6) StorageCraft ShadowProtect (1) VHDs (1) Intel RAID (2) Intel Server System R2208GZ (1) Intel Server Systems (17) RAID (2) SAS (2) SATA (2) Server Hardware (12) Microsoft Licensing (2) OEM (2) System Builder Tips (4) Intel (5) Intel Channel Partner Program (4) Intel Product Support (10) Intel Server Boards (2) Intel Server Manager (2) Cloud (26) IT Solutions (2) On-Premises (20) SMB (9) WIndows Azure (2) StorageSpaces (1) Error (47) Error Fix (35) Intel Desktop Boards (2) Intel SSDs (2) SSD (2) Business Opportunity (17) Data Security (11) Identity Security (7) Information Security (14) Privacy (2) Intel Modular Server (6) Promise (2) Storage Systems (9) Live ID (2) Microsoft ID (4) User Profiles (2) Articles (2) Building Client Relationships (6) DBCC IND (2) DBCC PAGE (2) filtered indexes (2) SQL Server Index Internals (2) training (11) Adobe (3) Internet Street Smart (8) Intel Storage Systems (2) LSI Corp (2) LSI SAS6160 Switch (2) Storage Spaces (7) Firmware Update (2) Product Support (7) Hybrid Cloud Solutions (3) Server Core (2) MAXDOP (1) SharePoint 2013 (1) SharePoint best practices (1) SQL Server Authentication (1) Family (5) Alternatives (1) SBS 2011 Standard (4) Microsoft Small Business Specialist Community (2) Microsoft Surface (2) SBSC (2) Networking (4) Availability Groups (3) CANITPro (1) HA/DR (1) Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group (1) webcast (1) VMWare (2) Conferences (2) Client Focus (2) Disaster Recovery (6) Error Workaround (8) Troubleshooting (4) Logitech (2) Product Review (7) Windows Features (4) XBox Music (2) SBS 2008 All Editions (4) MDOP (2) Microsoft Desktop Optimization Pack (2) Software Assurance (2) W2012E (6) Windows Server 2012 Essentials (6) Internet Explorer (3) USB 3.0 (2) USB Hard Drive (2) Bug Report (2) Microsoft Office 365 (5) sharepoint online (2) BitLocker (2) Windows (2) Microsoft Update (3) Swing Migration (2) Windows Update (4) Outlook (2) Group Policy (9) WS2012e (2) WSUS (3) Office (3) Microsoft Downloads (5) Microsoft Office (3) DRP (3) Virtual Machines (2) Virtual Server Hardware (2) online course (1) SQL Server learning (7) 2 Factor Authentication (2) 2FA (2) PASS Summit 2013 (4) SQLPASS (5) Contest (1) e-learning (1) Udemy (1) smbtechfest (1) backups (2) PASS Summit First Timers (3) IIS (2) RD Gateway (4) RD RemoteApp (2) RDWeb (4) Remote Desktop Connection (2) Remote Web Access (2) Remote Web Workplace (2) Cryptolocker (6) Backup (4) Restore (2) CryptoLocker (1) AuthAnvil (1) SBS 2003 (1) SBS Migration (1) Windows Server 2012 R2 (9) Documentation (1) IE 11 (4) testimonials (11) SQL Server 2008 (1) Best Practices (1) Support (1) Intel Xeon Processor (1) RemoteApp (1) Android (1) iOS (1) Hyper-V Replica (2) PowerShell (2) SBS (3) Break (1) Business Intelligence (1) Excel 2013 (1) Power Map (1) Power Query (1) PowerBI (1) MultiPoint (2) Surface (1) Net Neutrality (1) Opinion (2) ASP (9) HP (2) Scale-Out File Server (8) SOFS (10) Windows Phone (1) Updates (1) Intel NUC (1) Intuit (1) QuickBooks (1) Office364 (1) Intel Server Systems;Hyper-V (1) Firewall (1) Patching (1) Mobile (1) Mobility (1) sharepoint (1) Microsoft Security (1) Beta (1) Storage Replication (1) outlook (1) Hyper-V Setup (3) JBOD (1) Azure (1) PCI (1) PCI DSS (1) PII (1) POS (1) MicroStaff (2) Catherine Barr (2) Third Tier (1) BeTheCloud (1) BrainExplosion (1) LookAWhale (1) Manuel (1) Rayanne (3) SuperSecretNews (1) TechYourBooks (3) Managed Services (1) Training (1) E-mail (1)
RSS Feed
News
Aug
26
Domain Join Error: Cannot Complete This Function
Posted by Reprinted Article on 26 August 2013 11:53 PM

In our newly recovered SBS 2008 environment we have not restored our client's Windows Server 2012 DC.

When attempting to join a freshly installed Windows 7 VM via http://connect we hit the following error:

13-08-26 BIO-Recovery - 02 Cannot complete this function ERROR

Connect Computer Error Details

ERROR: Connecting to the network

Cannot complete this function

Now, we then went and tried to join the VM manually and this is what we hit:

image

Computer Name/Domain Changes

The following error occurred attempting to join the domain "domain.local":

Cannot complete this function.

After verifying that DHCP was only handing out the recovered SBS as the only DNS server we went on to clean out DSSite.msc of the secondary DC and then on to DNS to clean up domain.local and _msdcs.domain.local.

Once we cleaned out the references to the now absent DC we had a successful domain join.

Moral of the story: If a now defunct DC still exists in Active Directory Sites and Services and/or DNS then clean-up including metadata clean-up (KB216498) may be required.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



Aug
26
Domain Join Error: Cannot Complete This Function
Posted by Reprinted Article on 26 August 2013 11:53 PM

In our newly recovered SBS 2008 environment we have not restored our client's Windows Server 2012 DC.

When attempting to join a freshly installed Windows 7 VM via http://connect we hit the following error:

13-08-26 BIO-Recovery - 02 Cannot complete this function ERROR

Connect Computer Error Details

ERROR: Connecting to the network

Cannot complete this function

Now, we then went and tried to join the VM manually and this is what we hit:

image

Computer Name/Domain Changes

The following error occurred attempting to join the domain "domain.local":

Cannot complete this function.

After verifying that DHCP was only handing out the recovered SBS as the only DNS server we went on to clean out DSSite.msc of the secondary DC and then on to DNS to clean up domain.local and _msdcs.domain.local.

Once we cleaned out the references to the now absent DC we had a successful domain join.

Moral of the story: If a now defunct DC still exists in Active Directory Sites and Services and/or DNS then clean-up including metadata clean-up (KB216498) may be required.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



Jun
4
DNS on the Client: An Apology and a Learning Lesson
Posted by Reprinted Article on 04 June 2013 10:58 AM

Well, as mentioned on the final line in our previous post here:

It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.”

And, thanks to my fellow MVP Dave Shackleford taking the time to make things a bit clearer in the comments of the blog post, I now have a clearer picture of DNS on the client side.

My mistake was pulling the server round-robin structures into client.

In the case of the client, it will _always_ poll the primary DNS (DNS0 on the NIC/DHCP) server for its resolution needs. If for any reason something happens to the primary to cause it to not answer the client will move to the secondary DNS (DNS1 on the NIC/DHCP) and poll that server for about an hour.

So, my apologies for the misleading information. Lesson learned.

And, as Dave points out, and is our experience, if something causes a break between the primary DNS server and the client moves to the router or an Internet based DNS server that client will not move back in-house for a period of time.

What this means is that we still stand by our original premise on how the on-premises network should be configured to only poll DNS servers internally.

In a pinch the edge device can be set to deliver DHCP and DNS to clients if the only DC/DNS server goes down or a secondary DC can have the DHCP Role enabled but not online for backup purposes.

Thanks again for reading! :)

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



Jun
4
DNS on the Client: An Apology and a Learning Lesson
Posted by Reprinted Article on 04 June 2013 10:58 AM

Well, as mentioned on the final line in our previous post here:

It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.”

And, thanks to my fellow MVP Dave Shackleford taking the time to make things a bit clearer in the comments of the blog post, I now have a clearer picture of DNS on the client side.

My mistake was pulling the server round-robin structures into client.

In the case of the client, it will _always_ poll the primary DNS (DNS0 on the NIC/DHCP) server for its resolution needs. If for any reason something happens to the primary to cause it to not answer the client will move to the secondary DNS (DNS1 on the NIC/DHCP) and poll that server for about an hour.

So, my apologies for the misleading information. Lesson learned.

And, as Dave points out, and is our experience, if something causes a break between the primary DNS server and the client moves to the router or an Internet based DNS server that client will not move back in-house for a period of time.

What this means is that we still stand by our original premise on how the on-premises network should be configured to only poll DNS servers internally.

In a pinch the edge device can be set to deliver DHCP and DNS to clients if the only DC/DNS server goes down or a secondary DC can have the DHCP Role enabled but not online for backup purposes.

Thanks again for reading! :)

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



May
21
Repeat After Me: DHCP and DNS Belong on a DC
Posted by admin on 21 May 2013 03:01 PM

When configuring any network one needs to have an understanding of just how DNS works.

If DNS is not set up correctly there are so many things that break it is not funny.

Unlike mail routing (MX records) that offer a priority system for directing mail to the final destination where the system compensates for an offline mail server DNS operates in a round robin fashion.

So, if DHCP is set up on a router and delivers the following IPs for the client’s DNS queries:

  • 192.168.99.5 (local DC)
  • 192.168.99.1 (router)
  • 8.8.8.8 (Google DNS server)

Guess how many times the client’s on-premises resource DNS queries, in general, will fail.

If you guessed “67%” then you would be right.

It seems that folks are missing the reason for “Domain” in “Domain Naming System” or DNS for short.

The primary excuse we’ve heard so far to set the above DNS server IP settings on clients and even Remote Desktop Services servers and other servers is:

  • I want my clients to be able to browse the Internet if the DC and DNS goes offline.

There is, however, a fatal flaw in that line of reason . . . the missing “Domain” in DNS.

Or, to be blunt: A lack of understanding how DNS works on-premises and on the Internet and why the two are separate from each other.

Let’s have a look at this very crude drawing:

image

The left hand box is the on-premises Domain network. On that network MYDC is authoritative for that domain. Everything inside the box boundary for the network belongs to that DC and its on-premises DNS setup.

MYDC is the Start of Authority (SOA) for that domain (DOMAIN.LOCAL).

Being that our MYDC has the SOA means that no other DNS server _anywhere on the planet_ will be an authority for that domain. At least, for _that_ particular domain name in that particular location.

Not to mention the Top Level Domain (TLD) .LOCAL is not to be found anywhere on the Internet either.

What that means is that any client that queries DNS where MYSQL is will get the correct IP address from the DC that hosts the on-premises _domain’s_ DNS because that server is _authoritative_ for that domain.

Now, what happens on the client if they query DNS for MYSQL.DOMAIN.LOCAL and Google/OpenDNS server IPs are on the client’s DNS “where to query” server list and they respond?

That query goes OUTSIDE of the domain network to Google or OpenDNS and the response back is, “I have no clue who, what, or where the chicken DOMAIN.LOCAL is. Check ROOT SERVERS.” And of course, they answer same.

So, we have 67% of our on-premises queries failing DNS resolution.

Let’s think about that for a moment.

. . .

67% of our DNS queries are FAILING.

That means poor network performance, network print problems, LoBs that depend on database/SQL connections losing their connections, improper RDP routing, and so much more.

The _proper_ way to configure a domain’s DNS is as follows:

  • On the only DC on the network
    • AD and DNS are properly integrated
    • DHCP on the server
      • Name Protection Set (Ticks on 2003):
      • image
      • Admin credentials set to update DNS with IP:image
  • The DC NIC properties:
    • IP: 192.168.33.5
    • SN: 255.255.255.0
    • GW: 192.168.33.1
    • DNS0: 192.168.33.5 (SELF ONLY)
      • AD integrated DNS takes care of delivering IPs for other DC with DNS on the network. There is NO reason to put any other IP in DNS1.
  • DHCP configuration:
    • Scope Options:
      • 003 Router: 192.168.33.1
      • 006 DNS Servers: 192.168.33.5 (and other AD integrated DC/DNS server IPs)
      • 015 DNS Domain Name: DOMAIN.LOCAL
    • That’s it. Google/OpenDNS server IPs DO NOT belong here.
  • DNS Server service
    • Forwarders Tab
      • OpenDNS IPs or ISP’s DNS server IPs (at least two).

DHCP belongs on the server. Period. Full-stop.

If DHCP is on the router with DNS pointers to Google/OpenDNS or ISP DNS servers served to the on-premises DHCP clients then changes need to be made to put DHCP back where it belongs. . . on the DC.

If there is a concern about the only DC going down and leaving the clients helpless then make sure the backups are good.

If a need for redundancy is there then install an HP MicroServer with a Standard license and DCPromo that box into the domain. Make sure replication and AD integrated DNS are functioning between the now two DCs on the domain (we’ve seen situations where the second DC or RODC had no SYSVOL due to broken replication).

Or install an online cold backup device but make sure that the primary server has Software Assurance as Cold Backup is an SA only option.

For Small Business Server networks there _is_ a caveat to having another DC on the domain when in a disaster recovery situation.

In the end, a good chunk of the problems on a network such as connectivity, Line of Business application problems, performance, and more can have their source in an improperly configured DNS structure.

It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »



May
21
Repeat After Me: DHCP and DNS Belong on a DC
Posted by admin on 21 May 2013 03:01 PM

When configuring any network one needs to have an understanding of just how DNS works.

If DNS is not set up correctly there are so many things that break it is not funny.

Unlike mail routing (MX records) that offer a priority system for directing mail to the final destination where the system compensates for an offline mail server DNS operates in a round robin fashion.

So, if DHCP is set up on a router and delivers the following IPs for the client’s DNS queries:

  • 192.168.99.5 (local DC)
  • 192.168.99.1 (router)
  • 8.8.8.8 (Google DNS server)

Guess how many times the client’s on-premises resource DNS queries, in general, will fail.

If you guessed “67%” then you would be right.

It seems that folks are missing the reason for “Domain” in “Domain Naming System” or DNS for short.

The primary excuse we’ve heard so far to set the above DNS server IP settings on clients and even Remote Desktop Services servers and other servers is:

  • I want my clients to be able to browse the Internet if the DC and DNS goes offline.

There is, however, a fatal flaw in that line of reason . . . the missing “Domain” in DNS.

Or, to be blunt: A lack of understanding how DNS works on-premises and on the Internet and why the two are separate from each other.

Let’s have a look at this very crude drawing:

image

The left hand box is the on-premises Domain network. On that network MYDC is authoritative for that domain. Everything inside the box boundary for the network belongs to that DC and its on-premises DNS setup.

MYDC is the Start of Authority (SOA) for that domain (DOMAIN.LOCAL).

Being that our MYDC has the SOA means that no other DNS server _anywhere on the planet_ will be an authority for that domain. At least, for _that_ particular domain name in that particular location.

Not to mention the Top Level Domain (TLD) .LOCAL is not to be found anywhere on the Internet either.

What that means is that any client that queries DNS where MYSQL is will get the correct IP address from the DC that hosts the on-premises _domain’s_ DNS because that server is _authoritative_ for that domain.

Now, what happens on the client if they query DNS for MYSQL.DOMAIN.LOCAL and Google/OpenDNS server IPs are on the client’s DNS “where to query” server list and they respond?

That query goes OUTSIDE of the domain network to Google or OpenDNS and the response back is, “I have no clue who, what, or where the chicken DOMAIN.LOCAL is. Check ROOT SERVERS.” And of course, they answer same.

So, we have 67% of our on-premises queries failing DNS resolution.

Let’s think about that for a moment.

. . .

67% of our DNS queries are FAILING.

That means poor network performance, network print problems, LoBs that depend on database/SQL connections losing their connections, improper RDP routing, and so much more.

The _proper_ way to configure a domain’s DNS is as follows:

  • On the only DC on the network
    • AD and DNS are properly integrated
    • DHCP on the server
      • Name Protection Set (Ticks on 2003):
      • image
      • Admin credentials set to update DNS with IP:image
  • The DC NIC properties:
    • IP: 192.168.33.5
    • SN: 255.255.255.0
    • GW: 192.168.33.1
    • DNS0: 192.168.33.5 (SELF ONLY)
      • AD integrated DNS takes care of delivering IPs for other DC with DNS on the network. There is NO reason to put any other IP in DNS1.
  • DHCP configuration:
    • Scope Options:
      • 003 Router: 192.168.33.1
      • 006 DNS Servers: 192.168.33.5 (and other AD integrated DC/DNS server IPs)
      • 015 DNS Domain Name: DOMAIN.LOCAL
    • That’s it. Google/OpenDNS server IPs DO NOT belong here.
  • DNS Server service
    • Forwarders Tab
      • OpenDNS IPs or ISP’s DNS server IPs (at least two).

DHCP belongs on the server. Period. Full-stop.

If DHCP is on the router with DNS pointers to Google/OpenDNS or ISP DNS servers served to the on-premises DHCP clients then changes need to be made to put DHCP back where it belongs. . . on the DC.

If there is a concern about the only DC going down and leaving the clients helpless then make sure the backups are good.

If a need for redundancy is there then install an HP MicroServer with a Standard license and DCPromo that box into the domain. Make sure replication and AD integrated DNS are functioning between the now two DCs on the domain (we’ve seen situations where the second DC or RODC had no SYSVOL due to broken replication).

Or install an online cold backup device but make sure that the primary server has Software Assurance as Cold Backup is an SA only option.

For Small Business Server networks there _is_ a caveat to having another DC on the domain when in a disaster recovery situation.

In the end, a good chunk of the problems on a network such as connectivity, Line of Business application problems, performance, and more can have their source in an improperly configured DNS structure.

It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer


Read more »




Help Desk Software by Kayako Fusion