• 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 sbs

Apr
2

Mac Mini an Alternative to SBS?

by Third Tier

Post to Twitter Post to Facebook Post to StumbleUpon

In a March 31 article at crn.com (http://www.crn.com/software/224200956), ChannelWeb correspondent Kevin McLaughlin posits that Apple’s special configuration of a Mac Mini with Snow Leopard Server preinstalled could pose a serious threat to sales of Small Business Server. Third Tier’s Eriq Neale was interviewed for the article and offered some insight on the topic. To get a deeper view of Eriq’s take on the premise of the article, come to SMB Nation Spring in East Brunswick and sit in on his session Alternative Solutions in the SMB Space. Even if you saw the session he did at the Fall conference in Las Vegas, this is one you won’t want to miss!

—–

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
0 Categories : Announcement, Eriq Neale, Events, SMB Nation
Dec
18

Another reason SBCore could shut down your server

by Eriq

Earlier this month an associate pinged me about an unusual situation. He had an SBS 2003 server that was shutting itself down periodically, claiming that it was doing so because there was another SBS server in the domain. Well, this is expected behavior if there is, in fact, another SBS server in the domain, but this particular network had only one server, the SBS sever, and not a single other server or history of another server in the network. Another unusual symptom of the behavior is that the server would remain up for a little over 24 hours before it would shut itself down because of the phantom SBS server. According to MS KB 925652 the SBS server will shut down every hour if it detects another SBS server in the domain, so clearly a different set of events were causing this behavior. The server was logging SBCore 1011 errors in the event logs, but only after the server had been online for about a day.

On a tip from a colleague at MS, we started to look for a possible memory leak in the system. I worked with my colleague to set up perfwiz and poolmon to try to identify the process (or processes) that were leaking. The theory was that a runaway leak could strip the server of valuable no-paged pool memory which could cause the SBCore check to fail and generate the errors and shutdown event. I must admit, perfwiz and poolmon never were my strong points, so even after we got some results back, the review didn’t come up with a smoking gun.

Then my associate found a tip that I’d not heard of before, even though I regularly modify settings where this tip was found. He opened the Task Manger on the server, selected the Processes tab, then opened Select Columns under the View menu. In here, he enabled the “Memory – Non-paged Pool” column and then sorted the Task Manager process list by that column. Sure enough, he not only quickly found the culprit, but also could sit and watch the Non-paged Pool count grow steadily right before his eyes. The service causing the problem? spoolsv.exe, the print spooler service.

A quick bit of Googling on his part ultimately led him to this post from Tek-Tips which helped him identify the root cause of the problem: HP Standard TCP/IP ports for printers on the sever. He changed the port types for the printers from HP Standard TCP/IP ports to Standard TCP/IP ports, and the server hasn’t shut down again since.

Turns out, there is a KB on this situation, too, MS KB 933999. And in going back and looking further, the server was logging the Srv 2019 errors in the event logs as well. Since we were sidetracked by the anomalous SBCore behavior, we did overlook the 2019 as a possible factor as well.

In the end, I learned two things from this. One, you can track non-paged pool memory usage in Task Manager (which really isn’t a *revelation* per se, just something that I wouldn’t have necessarily deliberately gone out and looked for), and two, memory leak issues can cause anomalous SBCore errors and the shutdown of an SBS server. The good news is that the server was shutting down “normally” because of the SBCore misfire instead of totally running out of non-paged pool memory and crashing, as MS KB 933999 points out can happen. Bottom line, customer happy, and tech support further educated!

Categories : Eriq Neale
Sep
22

Chico and Sean Daniel get interviewed!

by steve

Check out Sean and Chico's Microspotting interview!

So when do I get to take a float plane ride with you up to your place? :-)

Categories : Steve
Feb
20

Setting up an external Autodiscover record for SBS 2008 or SBS 2011

by dave

Post to Twitter Post to Facebook Post to StumbleUpon

If you are using Exchange 2007 or Exchange 2010 (SBS or non-SBS) and are using a single-name certificate, this article is for you.

When you migrate to SBS 2008 or SBS 2011 and you already have a domain name, you don’t need to use the built-in domain registration wizard that is included in the SBS setup process.

This is well and good, but it has a downside worth knowing about. You probably didn’t know it, but something that Microsoft does when they set up your new domain name at the registrar is create a custom SRV record for your domain so that Autodiscover will work properly for external client auto-configuration. This is because you are using a single-name cert, which isn’t what Exchange 2007/2010 was designed to use. If you already have a domain name registered and are able to create your own DNS SRV records (some DNS hosts don’t allow SRV record creation), it would be a good idea to create an Autodiscover SRV record to make it easier for Outlook 2007/2010 clients to autoconfigure themselves for Outlook Anywhere (RPC-over-HTTPS) and ActiveSync.

The details on how to set this record up are all in KB940881, but I’ll briefly summarize it here:

1. Get rid of any CNAME or A records for “autodiscover”, and any wildcard “*” records in the public DNS zone. This is a critical step, so don’t just drift past it.
2. Build the SRV record to look like this:

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: remote.smallbizco.net

Why do you need to do this for Autodiscover to work? Well when you feed an Outlook client an email address, it tries to autoconfigure itself, and it does this by trying to contact a series of hosts as follows:

- https://domainname.com/autodiscover/autodiscover.xml
- https://autodiscover.domainname.com/autodiscover/autodiscover.xml
- http://autodiscover.domainname.com/autodiscover/autodiscover.xml

Because your certificate is tied to a single name: remote.domainname.com, any https connection to the autodiscover URL will fail. If you want to create an A or CNAME record for ‘autodiscover’ that points to your server’s public IP and allow port 80 to your server, autodiscover will work, but you would then have allowed port 80 traffic to your server.

An alternate option, still using SSL, is what this article is about. This method takes advantage of a feature that was added in Outlook 2007 SP1 that allows it to look for an SRV record and use the SRV record to find the “real” autodiscover host. In this case, the SRV record is pointing to remote.smallbizco.net, which is the name covered by the cert, so a secure connection to that server to get Autodiscover information will succeed.

Got it? Great!

BTW, if you have a single-name cert on a non-SBS Exchange 2007 or Exchange 2010 server, you still want to use an SRV record as described above, but there will be other changes you will need to make to your environment as well, primarily resetting the URLs on most of your Exchange virtual directories so that they all point to the name that is on your certificate. This is something that the SBS wizards take care of automagically.

—
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

16 Categories : Dave Shackelford, Exchange, SBS 2008, SBS 2011

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