I recently upgraded our office Mac Mini from 1GB of RAM to 2GB.  Afterwards I was having a number of issues with the machine.  Event with Macs using the Intel chipset there are still a number of differences in the system and startup procedures.  The Mac has a number of system controllers that cache settings, and occasionally become corrupt.  In the PC world, we don't have to worry about this, so it doesn't come directly to mind that you have to reset these controllers after making changes.

Resetting the Mac Mini:

Parameter RAM (PRAM) and Nonvolatile RAM (NVRAM):    Hold down Option-Apple-P-R while turning the power on.  Continue to hold until you hear the start sound twice. http://support.apple.com/kb/HT1379

Symptoms of corrupted PRAM/NVRAM - System unresponsive, Will not go past the Apple Load screen, frequent crashes or video problems.

System Management Controller (SMC):    Unplug all the cables (power, video, keyboard, etc.) from the mini.  Wait 15 seconds plug all cables back in.  DO NOT Hold down the power button while plugging in the power cable.  Turn on the mini. http://support.apple.com/kb/HT1543

Symptoms of corrupted SMC:  Fan runs constantly and loudly.  Performance problems. Computer sleep problems.

Power Management Unit (PMU) on older minis:    Unplug all the cables (power, video, keyboard, etc.) from the mini.  Wait 10 seconds plug all cables but the power cable back in.  Hold down the power button while plugging in the power cable.  Release the power button. Turn on the mini http://support.apple.com/kb/HT2183

Symptoms of corrupted PMU.  System won't start, peripherals won't work.

Tools for developing custom SharePoint applications: Visual Studio project templates for Web Parts, site definitions, and list definitions; and a stand-alone utility program, the SharePoint Solution Generator.

http://www.microsoft.com/downloads/details.aspx?FamilyID=7BF65B28-06E2-4E87-9BAD-086E32185E68&displaylang=en

I ran into a strange authentication problem in IIS on Windows Server 2003 SP1.  The website is configured for integrated authentication only.  I can authenticate and access the website no problem from any workstation on the network.  But from the console, I cannot access the website--it gives me a 401.1 HTTP error.  Strange.  The server can talk to the domain because I logged into the machine.  DNS looked good.

I ran across this little utility called AuthDiag.  http://www.microsoft.com/downloads/details.aspx?FamilyId=E90FE777-4A21-4066-BD22-B931F7572E9A&displaylang=en

AuthDiag directed me to a strange error message in the security logs, which led me to this KB article.

http://support.microsoft.com/default.aspx?scid=kb;en-us;896861

Specifically from the article...

This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

I decided to go with option 1 and set DisableLoopbackCheck to 1 and this fixed my problem.

CRM can be challenging to troubleshoot with log files scattered across several servers and often underlying problems that don't even appear in the logs.  I stumbled upon this diagnostic tool that was helpful in finding the problem with an SRS install.  Enjoy!

http://blogs.msdn.com/benlec/archive/2008/03/04/crmdiagtool4-for-microsoft-crm-4-0-has-been-released.aspx

I just wanted to post a little tidbit about the newer versions of DNN.  Specifically, I just installed DNN 4.8.4.  It went through the install process just fine and after that I tried to open the home page of the default portal.  I got stuck in an endless loop of redirects back to the home page.  In previous versions of DNN, this behavior was usually a result of a misconfigured PortalAlias table.  After spending time troubleshooting it from that angle I had to just start debugging the code.  I found a gem in the Page_Error handler in PageBase.vb that was causing my issue.

If objBasePortalException.Message.Contains("System.Web.Extensions") Then
    ' suppress AJAX error in Medium Trust
    Response.Redirect(strURL)

Googling for the exception message led me to this post http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/111/threadid/200731/scope/posts/Default.aspx.  Because I am using VS2008, my solution was to change the web site build settings to target the 3.5 framework instead of 2.0 so that the build would include references to ASP.NET AJAX.  Changing the build target to 3.5 fixed the problem.

Tomorrow, June 17th, is the long-awaited release of Firefox 3.  I have been using version 3 for quite a while now, and I've been using it at work since the Developer Tools were made compatible. It vastly improves both its performance and memory footprint over version 2, so the biggest complaints people have had about Firefox should be resolved.

Also, for you Opera users, 9.5 is out as well.

For those of you, like me, that have to support old sites for your clients, dealing with the vulnerabilities of old code can be quite a hassle.  Especially now that the best documented and known exploits can be completely automated.  One of our clients was recently subject to such an attack.  Unfortunately, when the site was originally developed, no real security was built into the code.  One user posted all SQL requests, no matter if it was coming from the public side or the admin side. All requests came directly from the page, meaning that every page had the code, and every one would have to be touched to really fix it.

As we were already redeveloping the modern replacement to the site, the client wanted us to spend as little time as possible on the old one.  So a true security audit was out of the question.  This, of course, is still the right way to solve the problem, but right isn't always in the budget.  So that leads us to a couple tools to help avoid the problem until we could release the replacement site.

The first is a tool from Microsoft called URLScan. URLScan has a lot of features, but what we used it for here was to limit the length of query strings.  Since the attack strings were almost always longer than a regular POST or GET, we just had to limit the length of the strings for most of those attacks to fail. Take a look at it, there's lots of neat tricks URLScan can do.

The big gun we used was an ISAPI filter written by Rodney Viana.  It's designed to scrub GET and POST requests of anything that would look like an attack.  It has been a life saver, especially when the attacks were happening hourly.

OneCare Connect Survey and Download

The new version of OneCare is now released for public beta.  OneCare now runs on Windows Server 2008!

FROM:

http://msdn.microsoft.com/en-us/library/wkze6zky.aspx

• Move or copy the assembly to one of the following locations:

  • The current project directory. (You can find these assemblies by using the Browse tab.)

  • Other project directories in the same solution. (You can find these assemblies by using the Projects tab.)

  • The Public Assemblies folder: Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Public Assemblies. (You can find these assemblies on the .NET tab.)

• Set a reference path to the directory that contains the assembly by using the Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#).

• Set a registry key that specifies the location of assemblies to display:

  Add one of the following registry keys, where <AssemblyLocation> is the directory of the assemblies that you want to appear in the Add Reference dialog box, for example, C:\MyAssemblies\.

  [HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"

  Note:

  Creating the registry key under the HKEY_LOCAL_MACHINE node allows all users to see the assemblies in the specified location in the Add Reference dialog box. Creating the registry key under the HKEY_CURRENT_USER node affects only the setting for the current user.

  Invoke the Add Reference dialog box again; the assemblies should appear on the .NET tab. If they do not, ensure that the assemblies are located in the specified <AssemblyLocation> directory, restart Visual Studio, and try again.

I need to strong name a few third party assemblies so that I could include them in a compile of a strongly named assembly that I was creating.  I found this site that did a great step by step on getting this working.

http://www.andrewconnell.com/blog/archive/2004/12/15/772.aspx

1. c:\>ildasm providedAssembly.dll /out:providedAssembly.il
2. Rename/move the original assembly
3. c:\>ilasm providedAssembly.il /dll /key=keypair001.snk