Showing posts with label DIY. Show all posts
Showing posts with label DIY. Show all posts

Friday, 17 October 2008

DIY's rope got long enough...

The proverbial straw that broke the camel's back:

DIY's billing for extra time where the client contact knows their arrival and depature times.

The suspicion flag getting raised: Selling as new what turned out to be refurbished Tier 1 systems. They were found out when one of those systems almost immediately failed and Tier 1 indicated it was already a refurb.

DIY initially refused to support it or even take it back. The legal flag was raised along with the cancelling of the cheque for the system. They relented and gave a full refund.

So, here we are.

Not only are things an utter disaster on their network, DIY was taking them for a ride and they were none the wiser ... At least until they hired their current office admin. She fortunately has enough computer experience to get the idea that things were amiss.

There is no substitute for a knowledgeable user!

She has saved them from the brink of utter disaster ... The possible toal loss of their organization's data and existence.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
http://blog.mpecsinc.ca

Sent from an SBS integrated Windows Mobile Device.

Dangerous DIY and Group Policy

More...

A domain level stand-alone GPO to run a script that does not exist.

A huge set of software restrictions in the default domain GPO with an Everybody scope.

It is a wonder that things have been running with this person managing their network as long as they have!

Wow.

A little bit of reading and a lot of formal training, or a lot of reading with a little formal training tied into running a lab to experiment and learn goes a long way to doing things right the first time.

There is no replacement for experience and mentorship!

Best Practices Analyzers! There is a very good reason or them.

With our client's businesses literally in our hands, we cannot afford to take our responsibility lightly.

We can never ever sit back on our laurels and say we know enough. The moment we do that, we and our clients are potentially toast.

Ugh! What a mess.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
http://blog.mpecsinc.ca

Sent from an SBS integrated Windows Mobile Device.

Dangerous DIY - "Knows what they are doing"

The entire life of a non-profit hanging by a thread:
  • No reservation for the server IP = .100!?!
  • DHCP set to infinite lease time.
  • DNS IP in DHCP pointing to a workstation IP.
  • DNS ISP settings in the internal NIC DNS Servers setting.
  • DNS not set to update from DHCP (that is pretty obvious as to why).
  • Roaming profiles setup with improperly set ACLs and share permissions.
  • Backups nonfunctional despite the assurance that they were running properly.
  • Workstation permissions messed up.
  • Printers set to static IPs with no reservations in DHCP for those IPs = lots of "I can't print" complaints.

There is just so much that is wrong here ... :(

This is the image used to explain what we are finding:

Someone has gashed their arm with an axe and the person who "fixed" it used a thousand band aids.
We will be installing a new SBS server here. And, given the frightful mess, we will be starting from scratch.

Hopefully we will not have to fight with Group Policy Tattoos and other problems carrying over from the existing 25+ workstations!

*sigh*

There is nothing more dangerous to the entire livelihood (20+ years on the edge of going down the toilet in this case) of an organization than a combination of arrogance and "I know what I am doing".

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

Saturday, 20 September 2008

SBS 2008 RTM install and some resources

We are in the process of running through our post OS install routine on an RTM version of SBS 2008.

The SBS 2008 RTM does not have anything overtly different from RC1 that we can see so far.

When working on the beta it was indicated to all of us that the RTM bits would be essentially an under-the-hood tweak of the RC1 bits.

The install went fine, and our post install routine is going well too.

Look for an SBS 2008 Setup Checklist to be posted here soon.

It will not be totally comprehensive by any means, but it will have a good number of steps to follow through on right out of the box!

The OS install portion may have decreased its install times exponentially, but it is looking like the post-install stuff is going to be quite time consuming.

As much as Microsoft has gone a huge step forward for the Do-It-Yourselfer ... there is still a huge window of opportunity for us I.T. specialists to get in there and do our stuff!

This OS is ripe for the tweaking ... in a way much more so than SBS 2003 ever was.

Check out:

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

Friday, 1 August 2008

SBS - .Local versus .com or others

We seem to see a fair amount of discussion around the .local top level domain (TLD) that we have been using in the SBS world for a while now.

Some links:
Whatever side of the fence you sit on: .local or .com, this week's fresh SBS install into a client we picked up a while back will reinforce, at least to us, the very valid reason for .local.

Qualification: That reason should never have existed in the first place.

Our client is a nonprofit. We have done sporadic support for them over the last three years or so as they have a very competent on-site person who can handle most anything. We were the ones she turned to when she ran into a wall.

Their budget came through for a new server. Working with them, and our support contact, it was decided that we would take on a more significant role in the supporting of their I.T. infrastructure to free up our contact to do other things.

Given the age of their Active Directory, and the need to restructure things accordingly, we elected to move the local desktops over the the new SBS domain, demote the existing server, and subsequently add it to the SBS domain as a member server only for the Line of Business app that ran on it.

While we took the time to look at the domain setup which was in place for a number of years prior to our contact coming on board with the organization, we never took too close of a look at it as we were dropping it all together.

The scenario:
  • Existing Windows Server 2003 domain NetBIOS: Workgroup.?
  • New SBS domain: NonProfit.local
Anyone want to guess what fell behind the workgroup.x?

Not taking a closer look initially was based on an assumption ... and we all know what happens when we do that right?!? ;)

Workstation #1 attempt to move to the new SBS setup:
  1. Log on as old domain admin.
  2. Reset local admin password.
  3. Open IE and point to: http://mysbs/connectcomputer
  4. IE opens: http://www.romancatholicparish.org/
Go to another workstation and the same thing happens.

Go back to the SBS box and open ISA's live query to see just what is going on and we see one IP address associated with the romancatholicparish.org (Note that the parish's name is the name of an RC Saint) and their Internet DNS servers in our SBS DNS Lookup Cache.

Huh?!?

First thought: Oh no, the DNS on this new SBS box has been poisoned or corrupted! But clarity soon ensued: Why in the chicken are we being redirected to an RC Parish and not some off the continent country infected Web site?

Just in case, the DNS patch was run on the SBS box and rebooted. We sometimes finish our patching after the SBS box has been installed on the network so WSUS picks up on the workstations in the new domain and if we are under the gun for timing as was the case here.

A deeper look into DNS pointed out to us just what was happening:
  • Local W2K3 domain: workgroup.romancatholicparish.org
  • WhoIs for above .org domain: Owned by an RC Parish in Kentucky!
Who ever had setup the original Server 2003 Active Directory had not registered the domain for whatever reason, and had not properly split the DNS probably assuming that the romancatholicparish.org domain would ever be registered.

Once we discovered this, the resolution was quite simple: Remove the workstations for the workgroup.romancatholicparish.org domain, and then run the mysbs/connectcomputer wizard. Note that one of the first steps on the machine was to reset the local admin password to a known quantity.

That worked!

From this experience, it is pretty easy to see why Microsoft has decided to stick with the .local TLD. The DIY or "consultant" doesn't have to understand DNS to set things up.

For those who are working with the RCx of SBS 2008, that hand holding even goes so far as to integrate Internet DNS management into the wizards to make sure that things get setup properly.

Those of us who understand the ramifications of DNS setups, .local or .com, registering the .com and splitting the DNS, and the reasons why we choose one over the other, can make sure our client's configurations are setup correctly.

However, all it takes is one DIY, or "consultant" to hose an installation on the DNS setup alone as was the case here.

Our vote goes with .local. It is a necessary "evil" in the SMB sphere to take care of the DIY that may not want to grasp DNS concepts and the "consultant" that has not taken the time to learn them ... yet.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.