Congrats Class of 2008

June 6th, 2008

I attended MSA’s graduation ceremony tonight. I have to admit, not to much has changed since my own (which was 5 years ago now for those of you counting). Time does fly.

Looking back now, it’s hard not to reminence about all the great times I had there as a student… MSA truly is a special place.. There are very few schools I believe that create as much community as that one… We’re an odd bunch, and we love each other more for it.

It’s rough though. This was what I believe may have been the last great class at MSA. Sure, eventually the other classes may live up to them… but I don’t know… There was something about the bunches of kids that attened the first, second, and third years of MSA that seemed special. The Bartz’s and Joe will be very very difficult to replace, and probably never will be…

But alas, I am not good with writing like this… so instead… I will post another pointless youtube video… This one I did… and is really just yet another test of something…

The FIRST Robotics Competition was this weekend (Thursday thru Saturday). I learned a few things from this that I thought would be worth sharing:

  1. It doesn’t take $1000’s of dollars to get 2000 people to a webpage a day… All it takes is something that 2000 people really want… Like a webcast of a live event where lots of the viewers are hundreds of miles away because the team was all that traveled.
  2. 2000 visitors per day is a lot of video bandwidth when streaming live. By a lot, I mean more than I would have ever imagined.
  3. People don’t get mad at you if it isn’t working if they have no way to contact you.
  4. It’s never to late to monetize a webpage that is getting 2000 visitors per day… (see:$5.00 in 5 hours doing absolutely nothing, yes I know, we aren’t rolling in it… but thats pretty dang good)
  5. It’s never to late to take advantage of Google’s search algorithm… Namely, the fact that 100’s of quick “high quality” links come in if you have something (aka, a live webcast) to promote. Just make sure you have the keywords where you need them.
  6. If your in high school/college, you should take part in as many team activities as possible… for they just don’t exist when your an adult.
  7. You can never have to much bandwidth.

I’m sure I learned something else too… Hmm… guess I’ll have to think harder.

Good Job Team 2175 (aka the Fighting Calculators)… Can’t wait til next year!

This is both for my own documentation, as well as to provide Google and others with a solution to this horrible problem. After searching the web, I was unable to find a solution that worked for me, so I got creative and tried a few of my own. Thankfully, one of them worked, or this would have been a longer day than it already has been.

Here are the symptoms:

  • Error Event Id: 1030 - Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine. This error occurs on the CLIENT machine anytime a user logs in or gpupdate /force is ran.
  • Error Event ID: 1058 - Windows cannot access the file gpt.ini for GPO CN= The file must be present at the location. This error also happens every time the user logs in or gpupdate /force is ran.
  • \\domain.local\ - Works but if you attempt to open any of the shares you get the error - \\domain\sysvol is not accessible. You might not have permission to use this network resource. contact the administrator of this server to find out if you have access to permissions.
  • \\server.domain.local\sysvol\ - Works just fine (weird)
  • pinging domain.local resolves to server.domain.local - Which is also as it should be.

Here is what I tried first based on research online:

  • Restarting Distributed File system DFS in the services menu (no affect)
  • Deleted all GPO policies and created new ones (no affect)
  • re-ordered my network cards priority by going to Network Connections->advanced->advanced. (no affect)
  • deleted and re-created my sysvol share (no affect)
  • check permissions on sysvol (they were all fine)
  • check DNS (all fine)
  • checked for errors in the server event log with regards to File Replications Server aka FRS (nothing)
  • checked various KB articles on Microsoft regarding the 1058 error… (no affect).

When it still didn’t work, I still needed a solution:

So here’s what I realized: DFS was working. The share itself was working… However, it appears that DFS takes over the sharename domain.local when it should be re-routing it to my domain controller. DFS isn’t nice though and will not let you recreate a new share with the sysvol name (at least not easily). So here’s what I did to fix it in the short term (and possibly the log term if it holds up):

  • Removed the share on sysvol (not normally recommend)
  • Opened DFS, and started the create a new root share
  • I then created a STANDALONE dfs root titled sysvol and pointed it at c:\winnt\sysvol\sysvol\
  • Created new group policy and tested it on a client (worked yay!)

I’m not sure that it will be the complete solution, but so far so good. I’m a little concerned about CertEnroll not working on the domain, as well as REMINST. It’s possible that the same trick will work to get them to work as well.

If you end up finding and using my solution, please leave me a comment, or if you found a way to improve it let me know.

Owning your problem

August 23rd, 2007

I kind of want to document this because odds are I will do it again.

Active Directory is a domain server that is built into Windows Server 2000, 2003, and probably all future versions of windows server. Basically it’s user and policy management for rather large networks. It integrates “well” with exchange server (email) as well as a half dozen or so other Microsoft server products.

Well, for security reasons, when you connect up a computer to the domain, there is an exchange of “keys” as the “machine” joins the “domain”. These keys are more or less unique to the individual machine, such that, if someone trys to do something on the domain using another machines name, it’s not allowed.

Lately, I have been trying to get a Samba 3 file server working within our domain at MSA. So far, getting it to do what I want hasn’t happened. In the process of trying to make this happened, I found out something interesting.

See, when you join the domain, you first name the computer, and then use administrator credentials to get it joined. It turns out, that if you name a machine the same thing as your domain controller, and then join using administrator level creditials, very bad things happen… Especially if you only have 1 domain controller.

Quite a few weird things start happening. Logins stop workings. Shares stop working. Errors everwhere.

Turns out the fix it quite simple, once you find it. You simply have to re-add the original server to the domain. The steps can be found here:

http://support.microsoft.com/kb/260575

So, you may never work with an Active Directory server, but if you do, and you ever have a problem like this… give this a whirl. Now if only I could solve the original problem.