Need to generate a new GUID but don’t have any developer tools installed?
This is easy with PowerShell. Just enter the following command:
[System.Guid]::NewGuid()
You will get an output similar to:
Guid
----
3ca14ab2-21c9-4c16-956a-55f303f2fbb7
Of course if need be you can assign the new GUID to a variable and use it from there in your scripts.
Enjoy.
Just recently I was trying to track down an indexer issue on MOSS 2007 in the Shared Services Provider (SSP). The error was "Error in the Site Data Web Service" in the location of http://<ssp web host>/ssp/admin/Content.
After digging around in the logs I found an error to the call: GetWebDefaultPage. After pointing SharePoint Designer at this Content sub site (which hosts the BDC entity display template pages) in the SSP host, I found out that there is no default page (default.aspx).
You can do 4 things to solve this problem.
I am not convinced Option 2 is a good idea as it could lead to strange searhc behaviour especially with BDC applications.
In our environment, we decided on Option 4 as we had no need to index the SSP at the moment.
I hope this helps.
Nate
Reason: Exception from HRESULT: 0x80040D1B
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (GUID) threw an exception. More information is included below.
I came across this error just recently. It all started when the installation of VS 2008 on my laptop (Vista 32Bit) seemed to fail. My symptoms were:
I did notice just in the last 2 weeks that my system fonts changed to an Italic font. I didn't understand what set this, but I did think it looked cool so I left it. (I believe the change occurred when I set the Aero colour theme).
It turns out that VS 2008 was having issues with the font Segoe UI.
I fixed this by going to the "Font and Colours" section of the Options pages and changing fonts marked as "Segoe UI" to Calibri and setting the "Environment" font to Calibri as well (From Automatic).
This seemed to have fixed the issue.
Post Update:
Since posting this article, I also found the same issue with the SQL Server Management Studio.
So I changed my fix. I reset the font and colours in VS 2008 to their defaults. Then I changed the Segoe UI font to Calibri in the Vista system settings for Windows Colours and Appearances. I changed the fonts for the Aero colour scheme.
Everything appears to work again.
While browsing around my local DSE store this evening, taking advantage of the really late night shopping, I noticed an interesting display in the entertainment section.
This display was for "Monster" Brand AV cables, in particular the Monster brand HDMI cable. The display had 2 Samsung 56cm LCD TV placed side by side and both playing a synchronised feed of the movie "Cars". Behind the TVs was a cardboard backdrop advertising the Monster Brand HDMI cables and why they are the most superior. Above the right TV was a sign that said "Monster Cable" and above the left TV was a sign with "Standard Cable" printed on it.
I noticed that the right hand TV had an extremely richer picture than on the left.
The curious person I am started looking at the back of the TVs. On the right - a Monster Brand HDMI cable was plugged into the HDMI port. On the left TV a cheap, low quality composite cable (it was actually one of the cables from a stereo RCA audio cable) was plugged into the "Video In" port of the TV.
When questioned about the point of the display, the clerk said that they are showing how HDMI is better that composite. I explained to him that the display was a little misleading, using the term "Standard Cable" in a display that is selling the benefits of a Monster Brand HDMI cable. The Clerk did say they were clearly labelling it as a standard composite cable - Yeah right! I can just see it now. A customer that doesn't have the understanding of the different AV connectors, buys a brand new HD TV and a Blue Ray DVD player. When looking for a HDMI cable to connect the two together, they see this display and say "Geez, the colour is a little washed out with the standard cables, I better get the Monster brand" - And they part with $200-$300 on a cable they don't necessarily need.
Buyers, watch out. Make sure you are 100% comfortable. If something doesn't seem right, then question it. Just remember, you are in control of the situation. You can walk at any time. When shopping for TVs and cables and DVDs etc don't be scared to swap the cables around, change the channels on the display units even eject the DVDs playing to ensure they are the real deal just so you can be sure there is no trickery going on.
FYI - I connect my Media Centre to my plasma with a $40 DVI -> HDMI video cable (from Radio Parts Group) and get superb picture quality at 1080P.
An interesting title I know, but after a recent experience and typical day-to-day operations, I figured it was time drag out the Soap Box and try to have a philosophical moment.
"So what has brought this on" I hear you ask? Well, like I mentioned above I have had a recent experience. Now to ensure I don't get in too much trouble, here is the summary of the experience:
I received a phone call the other night about a strange buzzing sound coming form the bathroom of a family member's home. After asking all of the logical questions:
I then progressed to the not so obvious questions:
When I went around to the house, I put my head in the roof but couldn't hear the noise. I went into the bathroom and removed the fan cover. This is when the noise appeared to come from the shower recess. Although this has baffled a a couple of people, after careful listening, the cause of the noise was obvious and in plain sight.
This has made me think, are problem solving skills something you can learn or is it something you are born with.
Coincidentally, I actually had this same conversation about a week prior with an academic colleague. The conversation started when we were discussing hiring graduates (which I look upon in a highly positive way). My colleague mentioned that in the IT educational system today, Computer Science is not what it was previously. "Today it is all about learning to program in Java or C#, and it is no longer about applying algorithms to solve the problems". I will be the first to say that I don't necessarily know about all of the different documented algorithms there are to solve problems - but I digress. My point is, this is just one facet of problem solving in IT. In this instance, my colleague believed you cannot necessarily teach problem solving skills.
But there are other facets of IT when it comes to problem solving. Take for example the infrastructure side of IT, supporting the servers and application software that we use on a daily basis. I would be a liar if I didn't say that it is not always smooth sailing.
I believe that good software should not be judged solely on the functionality that it offers. When evaluating a product, it is important to understand the way it can be supported as part of the process. All the cool features and widgets would be useless if the software stops and you cannot return it to service. Software engineers should, in general, ensure their code contains enough debug support code, so that if an issue should arise, it can help the supporters pin-point the root cause. By debug support, I mean, entries in Windows Event Logs and File logs etc. And, oh yes, this needs to be able to be turned on when the issue arises, without destroying the current symptoms (so don't put it in the Web.config :) )
But even with all of these wonderful "support aides", you still need people with good problem solving skills to debug the situation.
So, how do I try and solve a problem? Well I have a really simple process that I follow. This process is inspired by the CSI TV shows - which is basically "Follow the evidence!". Look in the event logs and note the errors that appear to highlight the symptoms. But also look at the errors that occurred before and after the events. Look for multiple cases of the error. This will help you get an idea of all the symptoms. Hopefully this is enough to provide root cause and therefore a solution. But more often than not, it doesn't.
This leads you into the next step of the process: Internet Search. I am a firm believer of "Googling" (Yes it hurt me say this - But "Windows Live It" - well it doesn't really roll off the tongue) the event log messages. Why? Well unless you are sitting on the bleeding edge of technology, I am pretty confident to say, you are not the only person in the world that has experienced this problem. You might be unfortunate as to be the only person that has written about the problem though...
If still no luck in obtaining root cause (or there is no simple fix), then you need to reproduce the problem. This should / must be performed in an isolated lab environment. Tinkering in production is not recommended and should be avoided wherever possible. So if you can reproduce the symptoms in the lab environment, then this is where you should start. Now this is where a little discipline goes a long way. Try to make only one change at a time, and ensure you document each and everyone. This is important, because if you fix it, and you can't remember how, well then you are no better off - right?
The most important step at the end is to share the knowledge. Document it, tell somebody, blog it, write it up in your Knowledge Base system (Don't have one, try WSS 3 and the KB application template). This ensures the information is shared and if the problem occurs again, someone else can fix it. Also, if you believe in Karma and what goes around, comes around, well you will be sorted again on your next issue.
So, I might have digressed a bit, but not really. So, having shed some insight into my problem solving process, do you conclude that I am a good problem solver or a good Internet searcher? Well, I believe, a bit of both. It is not possible to know everything. We in IT are constantly playing catch-up. Understanding the basics of how things work combined with the ability to research does give you the edge to solve any issue. What I can't believe is how many times I ask people if they have searched the Internet looking for the symptom. What I don't understand is why people don't do this first? In actual fact, this is a real interview question I ask of potential candidates, where the outcome can be influenced by the answer to this question. Showing an understanding of technology is one thing, but when you are stuck, following a process and learning from it is another.
I remember once interviewing a new graduate. Being once a graduate myself, I understand that you don't have real world experience and getting your first job can actually be rather difficult. But this one interview I remember vividly:
Me: "Assuming that you have done some sort of hands-on project for your studies, tell me about a time when you were stumped and how did you resolve the problem?"
Candidate: "It was some C++ code. I went to the lecturer, and he resolved it for me".
Me: "Ok, so what was the solution?"
Candidate: "I don't know, the lecturer fixed it for me."
The interview then ended.
Now, I didn't care too much that the lecturer solved the problem, but it was the sheer lack of learning from or caring for the solution that killed it for me.
I believe that problem solving skills can indeed be learned. It comes with experience. Every problem is different, and every solution brings with it a new set of learning's that assists with the next problem to solve. But, it is a 2-way street and you must want to learn from your experiences in order for your skills to be enhanced.
As a final point, my learning has showed that the absurd theories for the root cause of the problem should never be ruled out until they have first been proven wrong. Technology is a wonderful thing in that in most cases its never what you expected (I suppose that ties into "Its always in the last place you look" - well dah!)
But seriously take these snippets as an example:
Example 1:
Symptom: Lotus Notes Client published through Citrix runs extremely slow. Servers well resourced with low load. Doesn't affect everyone, only certain people.
Root Cause: Dual monitors on certain desktops claimed extra server memory and resources resulting in slow performance of the application.
Stump Time: Few days
Example 2:
Symptom: SQL Server 2005 replication schedule fails. Event logs display the following:
The job failed. Unable to determine if the owner (domain\username) of job SQLJobName has server access (reason: Could not obtain information about Windows NT group/user 'domain\username', error code 0x5. [SQLSTATE 42000] (Error 15404)).”
Root Cause: SQL Server Service Account password expired and it could not contact the Active Directory to validate if the Job Owner was a valid account.
Stump Time: about 1 day duration. Including a large audience of people involved. Fix time: 2 minutes.
Oh and by the way, It was an electric razor vibrating against the "shower caddy" in the shower!!!
Posts
All Comments
