9/3/2010If you've ventured into the world of PowerShell extensions and modules, and more specifically, that world, targeted at SharePoint, then you have probably run into this error before. Import-Module : Could not load file or assembly 'file:///C:\cjvandyk.SharePoint.PowerShell.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. At line:1 char:14+ import-module <<<< .\cjvandyk.SharePoint.PowerShell.dll + CategoryInfo: NotSpecified: (:) [Import-Module], BadImageFormatException + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.ImportModuleCommand This error is thrown by PowerShell when you are using the Import-Module cmdlet to import a PowerShell module (redundant, isn't it?) that was built using the .NET Framework 4.0. The ugly error looks like this: 
If you're trying to use that module on a SharePoint system, the odds are that the server does NOT have the 4.0 version of the Framework installed. You can easily confirm this by simply checking the sub folders under the C:\Windows\Microsoft.NET\Framework location.  In the above example, you can see that 1.0, 1.1, 2.0, 3.0, 3.5 and 4.0 are all installed on the server. If you find that 4.0 is NOT installed, you can quickly install it following this guide. Once it's installed you only have one more thing left to do. By default, PowerShell will run under the 2.0 Framework. We need to force it to default to the 4.0 Framework and only revert back to 2.0 if it doesn't find what it's looking for in 4.0. That is easily done using a .config file for the PowerShell executable. Browse to the C:\Windows\System32\WindowsPowerShell\v1.0 location. 
You may not have the two .config file on your system. If you don't, you need to create them manually. Name the files exactly the same as the .exe files, but with a .config extension at the back. Create them as text files, but you will need to show extensions from your Folder Options in Windows Explorer in order to get rid of the .txt extension. The two config files should be named "PowerShell.exe.config" and "PowerShell_ise.exe.config". The content of the two files is a simple XML snippet that simply points PowerShell to default to 4.0 and fallback to 2.0. Copy and paste the following snippet into the .config files. <?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
Now when you restart PowerShell, attempting to load your module should yield no errors (if your module is compiled correctly and valid), and you should be able to implement the functionality from the module without any problem.
Enjoy
C
   
8/27/2010When you enter STSADM -o deletessp from your SharePoint web server command line, you should get this: 
If you then proceed to try and delete your SSP with a command such as STSADM -o deletessp –title SharedServices1 but it still fails to delete, then you could use the undocumented -force flag thus: STSADM -o deletessp –title SharedServices1 -force Which should yield this: 
Gotta love those little –force flags. Later
C Technorati Tags: SharePoint, STSADM
8/19/2010This one was undocumented in SharePoint 2007 / WSS 3.0 and is still undocumented in SharePoint 2010 / SPF. I posted about this back in 2007 for the previous version, but was asked the same question in the SharePoint Support Forums. A little digging and firing off a test confirmed that the command has stayed intact for the latest version as well. Using STSADM from a command windows: STSADM -o setproperty -pn max-template-document-size -pv 524288000 Let it run and upon completion, you should see this: 
Later
C FOLLOW ME: 8/9/2010Another quick one… You can run this stored procedure: exec sp_databases
Which should yield the following output:
or you could try this stored procedure: exec sp_helpdb
Which would yield some more extended information thus:
or if you just want the names, you could execute this “undocumented” stored procedure: exec sp_msforeachdb 'print ''?'''
Which will yield this:
Or you could do the manual step of executing the following select query: select name from sys.databases
Which will yield:
Enjoy
C
FOLLOW ME: 8/2/2010Every so often, you run across the need to redirect a page somewhere else, like after a server migration when DNS isn’t used. By simply adding a HTTP-EQUIV meta tag to the <HEAD> of your page, you can redirect elsewhere in a jiffy. Syntax isn’t complex, but must be correct to function properly. Here’s the syntax: <HTML>
<HEAD>
<META HTTP-EQUIV="refresh" CONTENT="SECONDS_HERE;URL=REDIRECT_URL_HERE">
</HEAD>
<BODY>
</BODY>
</HTML>
Later
C
Technorati Tags: HTML RedirectFOLLOW ME: 6/21/2010If you’re receiving this error, you’re probably trying to merge one XML node into another. Your code could look like this: XmlDocument xmlDoc = new XmlDocument();
...
xmlDoc.Load(strXmlFilePath);
XmlNode nodParent = xmlDoc.SelectSingleNode(strParentXPath);
XmlNode nodFragment = xes.GetXmlNode(strFragmentXml).FirstChild;
...
nodParent.AppendChild(nodFragment); You could even be trying .Clone()
XmlDocument xmlDoc = new XmlDocument();
...
xmlDoc.Load(strXmlFilePath);
XmlNode nodParent = xmlDoc.SelectSingleNode(strParentXPath);
XmlNode nodFragment = xes.GetXmlNode(strFragmentXml).FirstChild;
...
nodParent.AppendChild(nodFragment.Clone());
But alas… the .ImportNode() is what is needed…
XmlDocument xmlDoc = new XmlDocument();
...
xmlDoc.Load(strXmlFilePath);
XmlNode nodParent = xmlDoc.SelectSingleNode(strParentXPath);
XmlNode nodFragment = xes.GetXmlNode(strFragmentXml).FirstChild;
...
nodParent.ImportNode(nodFragment.Clone(), true);
Enjoy
C
Technorati Tags: XML MergeFOLLOW ME: 5/4/2010As a SharePoint Developer, you may run across this error at some point. 
It is most common when you’re trying to recompile a SharePoint binary, from a Visual Studio session ON the actual SharePoint server. Of course, in most normal situations, it’s unthinkable to run the compiler on the server, but as SharePoint developers, we know there is no other way to code for the platform so it’s pretty much SOP for us. The problem lies in the locks that are taken by the compiler process on the debug info file. Often the locks are taken by your last debug session and unfortunately the locks aren’t always released, even though you’re the same user from the same application. Call it a multi threading anomaly or something. Whatever it is, this happens in Visual Studio 2008. Enter Process Explorer! This little gem by Mark Russinovich from SysInternals, has been around for a long time, now in it’s 12th version. Microsoft bought SysInternals a couple of years ago, and with it, Mark’s great mind. I must say, it was probably one of the smartest acquisitions that Redmond has ever made. But I digress. So, if you have Process Explorer installed (if you don’t, download it now and do so), it generally lives in the C:\Program Files\Process Explorer folder. To unlock your files and resume your compilation, follow these easy steps: -
Open Windows Explorer. -
Browse to the C:\Program Files\Process Explorer location, or any other alternative location where you may have installed Process Explorer to. -
-
Double click “Procexp.exe” to launch Process Explorer. -
Once Process Explorer opens, it will display a list of all active processes on your system. Odds are that your .pdb file is NOT shown here. -
In the top menu, click the “Find” menu item. -
In the drop down menu, click the “Find Handle or DLL” menu option. NOTE: If you’re a shortcut kinda guy or gal, you could have accessed this option with the “Ctrl+P” keyboard hotkey combo. -
-
In the Process Explorer Search dialog window, enter the name of your DLL, or in our case, the name of our .pdb file. -
Click “Search” or press “Enter”. -
-
Process Explorer displays the process that has the lock and wouldn’t you know it, it’s Visual Studio itself.  -
Double click on the “devenv.exe” line. -
Process Explorer now closes the dialog window and the “devenv.exe” item is added to the displayed list. -
Right click the “devenv.exe” line in the displayed list. -
-
On the popup menu, click the “Close Handle” menu option. -
Process Explorer will display a warning message noting stability and crashes that may be caused by closing the handles on this file. Of course we understand this and we click “Yes”. Or alternatively, we don’t understand but as a Windows user, we blindly click “Yes” to just make the popup go away.  -
-
After closing the handles, we return to Visual Studio and press F5 or click Rebuild and tada!  -
Happy coding! Later
C 4/19/2010I’ve been helping a good client of mine trouble shoot some performance issues with their SharePoint environment. They have a single MOSS 2007 server under 32 bit, so their 1,000+ active users (not concurrent though) is stretched about as thin as it will go. Recently, the server started having issues where the app pool would get locked up and take all the users down. Now IIS app pools are designed recycle when certain limits are reached so that it would be seamless to the end user. The app pool was set to recycle when memory consumption under the worker process (w3wp.exe) reaches 1 GB or the virtual memory consumption for the app pool reached 1.9 GB. We were not seeing the overlapped recycle taking place automatically because the app pool would get locked up when memory reached around 940 MB. It was not consistent though so it couldn’t be identified readily. We ended up trimming the values back to the eventual 800 MB physical and 1.5 GB virtual memory before triggering a recycle.  Once the app pool reached either of those limits in it’s memory consumption, IIS would spin up a new w3wp.exe worker process with a fresh app pool and all new SharePoint requests would be directed to that process instead. All existing pending requests on the current worker process/app pool would complete or be terminated once the timeout configured in IIS was reached. After all requests completed and released their execution threads, the worker process would terminate and release it’s memory back to the pool for IIS to use.
If you are seeing similar behavior in your SharePoint environment, there are a couple of things you need to pay attention to: - IIS Timeout setting.
- Runaway/locked up threads.
- Time between recycles.
- Physical server memory.
- Bit architecture of the server and SharePoint.
Once your server isn’t crashing for end users any more, it’s time to tune it’s health more closely. Identify what the IIS timeout setting is set for, for your server/app. If your server is still on IIS6, you will want to ensure that the LogEventOnRecycle property in the IIS metabase is set to true. Next you want to look in the Event Log under System for message 1077 which indicates that an overlapped recycle took place for the app pool. Make sure to note the time between these messages. It’s best to use the smallest time which should relate to your peak volume time of day for the given server. Lastly you want to make sure how much physical memory the server has and what the bit architecture of the server, the OS and SharePoint is, i.e. are you running 32 bit or 64 bit.  Now it’s time for some math. If you have a 32 bit server running 32 bit Windows Server and 32 bit SharePoint, this is a much more crucial issue than if you were running all 64 bit. The issue deals with memory. You have to figure that the server will not realistically have available to your worker processes more than half of it’s actual physical ADDRESSABLE memory. I highlight addressable here because remember than under 32 bit architecture, your server cannot address more than 3.2 GB of memory, even if it has 8 GB of physical memory!
Thus in our all 32 bit example, even though the server has 4 GB of memory physically, the OS can only address 3.2 GB which means by my math, about 1.6 GB would be available to our worker processes in IIS. You may be tempted to use something just below that as your recycle point, but remember that we have OVERLAPPED RECYCLE going on which means that IIS is managing two worker processes at the same time, so each would require it’s own memory in order to function properly. That was the problem we ran into when the recycle threshold was set at 1 GB. The worker process would trip the limit and then IIS would attempt to spin up an overlapping worker process, but since there wasn’t enough memory available to do so, it took no time at all to completely lock up IIS and bring down end users. Only a forced recycle of the app pool, which forcibly releases all threads and memory pages, thus also dropping users, before spinning up a new worker process, could restore the server to a working state. Dropping the memory recycle trigger down to 800 MB instead, we consumed half of our available memory, or 25% of the addressable memory. When the worker process triggered the overlapped recycle, it would spin up a second worker process and direct traffic to it while finishing up requests in the first worker process. Provided none of these requests had runaway threads, the worker process would typically shut down and release memory within a minute or two.  This gets the server into a usable state as far as the end user is concerned because they no longer see crashes or get locked up. On the server side, you will see the app pools recycle much more frequently and you are running the risk that a runaway thread would lockup the first worker process until the IIS timeout is reached. That setting is 15 minutes under IIS by default, but most SharePoint shops have upped that to 30 minutes, especially where low bandwidth or VPN users are in play. As a result, a runaway thread would keep the first worker process alive for 30 minutes. You can see how the time between recycles now becomes super CRITICAL! If you overlapped recycles happen more frequently than your IIS timeout value, change something.
RECOMMENDATION: Ensure that your IIS timeout value is always LESS than your overlapped recycle time at it’s shortest interval. Of course the answer is to solve the memory leak problems so that the app pools don’t have to recycle, but if you’ve ever tried to track down memory leaks, you know it’s HELL!  If you’ve never had the misfortune of having to do so, consider yourself truly blessed. It’s also not always realistic to bring the IIS timeout value down. If your server is recycling worker processes every 15 minutes, it’s certainly not likely to be doable. That’s when it becomes mission critical to hunt down any runaway threads and determine their cause. Anything that may cause the worker process to remain alive need to be addressed in order to keep your server up and running. At my client’s site, we were still getting runaway processes that could potentially put us in a state where a third worker process needs to be spun up which would bring the whole thing to a screeching halt. As an Enterprise Architect I get to see all sides of the fence. I work with and talk to everyone involved. When talking to developers, the feeling is usually that Ops people must have done “something” to the servers which is causing the instability. When talking to operations personnel, the feeling is usually that Devs are writing bad code that’s causing the instability. I’ve been in many SharePoint shops and have seen both sides of this argument be true, but not this time. We had an awesome traffic profiling tool available for the job and that’s where we discovered two items that would cause runaway threads. -
 SQL Server Reporting Services Integrated Mode. If you’re a SharePoint Architect, you probably just had a cold shiver go over your entire body as you read that line. Yes, every SharePoint shop dabbles with SSRSIM at some point. Most come to the conclusion that performance is a problem and usually deploy a dedicated server to run SSRS. That was also the case here. Unfortunately, there was a couple of instances of IM reports that could not be moved over to the dedicated server so IM was left active. What we discovered was a series of reports developed and built (as SSRS empowers end users to do) by end users. Of course end users are not going to know how to write optimized queries for data so as a result, these reports performed poorly. There were reports that would take upward of 30 seconds to load, and that was being local to the servers and on a 1 GB ethernet connection. The reports have very large amounts of tabular data and we know how well IE renders tables. Imagine being a user, on a remote VPN connection. Your wait time on the report could easily go over 2 minutes. The problem with that is the thread requesting data is locked up while all this data is transferred and interpreted for render on the browser. Additionally, a user could easily lose patience and simply close their browser fearing that it may be “locked up”. When a user does that, the thread still remains alive in the background until the download is complete and the loss of the end point on the client side could very well cause the thread to become a runaway thread that never releases its resources. No matter how you slice or dice it, it’s bad. -
Image Rotating Banner. We have a nifty little web part that adds pizzazz to user created pages by rotating through images determined by the designer/user. Now as I said, any time we empower end users to do design of content delivery, a LOT of thought has to go into it. In this case, the web part was designed for ease of use in that all the designer/user had to do was drop it on the page, set the Title for it and point it to an Image Library on the site. Then when the page is loaded, the web part would start rotating images using JavaScript. Nice. But way, there’s more. Using our awesome traffic profiling tool, we discovered pages, like main departmental home pages, were loading literally dozens of images. Taking a closer look at the pages, they appeared to load rather slowly. If you’ve ever dissected the loading sequence of a SharePoint page, you’d know that, even if you set them to display partially while downloading content, the JavaScript is usually the last part to be downloaded. As a SharePoint developer would understand, a SharePoint page isn’t really functional until that JavaScript has loaded. None of the dropdowns work etc. But I digress. Needless to say, until the page is completely loaded, you can’t really do too much. What we saw was all these images loading with the page before the script would load, making the page load times very slow. To make matters worse, we looked at some of the pictures being loaded and most were not resized to the 100 pixel banner size they displayed in. On the contrary, the images were in their original 9 mega pixel JPG format!  Cracking open the code for the web part, we discovered that it did exactly what I just described. It showed ALL of the pictures in the picture library regardless of SIZE. Though that design is OK for uses where experienced developers or web designers would be using the web part, it unfortunately does not work well for end users or inexperienced designers because it’s not realistic to expect an end user to think about the number of pictures being displayed, all being preloaded on the page as well as the size of those images. Considering some images up to 5 MB in size and libraries easily containing in excess of 20 images, you can see how the 1 MB size page, now having to preload all these images, suddenly became a 100 MB+ page. That’s never good for performance. Now granted, the web part should probably use AJAX to load it’s images and not preload them on the page, but this was the design that was available. We implemented a hot fix to the code whereby we simply leveraged SharePoint’s built in thumbnails for image libraries since it’s just a banner anyway. In addition, we display only a random 10 images from the library each time. That meant no more than 100 KB in extra page size. Again, you can see how a user could easily give up and close the browser, leaving a thread locked as it processes. As we’ve seen in this case, as developers and architects, we always have to be conscious of our end users. Tools we provide them in order to empower them can often come back to haunt us at the most inopportune times.
Later
C
4/12/2010SharePoint maintains some built in thumbnails that’s automatically generated when images are uploaded to the image library. This is in order to allow for the thumbnail view of the image library. Here’s an example from my blog. 
On the left side is the original  image that exist in the image library. Click on the link to see the image in it’s full size. The right side is the SharePoint thumbnail. You can click it to see the size of the image. The formula is pretty simple… simply change the URL as follows: Original: http://www.cjvandyk.com/blog/Lists/Photos/042308_1817_VMWareSnaps3.png Thumb: http://www.cjvandyk.com/blog/Lists/Photos/_t/042308_1817_VMWareSnaps3_png.jpg As you can see, simply: -
Insert “_t/” in front of the file name, -
Replace any periods (.) with underscores (_) and finally, -
Append a “.jpg” at the end of the file name. As you can see, my example was actually a .png file, but the thumbnail is still a .jpg file. Enjoy
C 3/29/2010*UPDATE* I had the opportunity to test this utility with Remote Desktop in full screen mode recently and it worked like a dream! 
OK, really quickly. I love playing my strategy games. One of my long time favorites has been Hearts of Iron II – Doomsday Armageddon. This game plays on my Netbook just fine, so it’s an easy one to spin up on the plane etc. The crew over at Paradox Interactive sure did a good job on the game’s logic engine. Anyway, as I said, I love playing this game. The only thing is that there’s one small problem with it on the Netbook. See, when you are playing full screen graphic games, things like system warnings of battery low status and the like, simply does not pop up over the game. As a result, you’d be playing your game happily when all of a sudden, the Netbook would start going into Hibernate. That’s all good and dandy, but see, the problem under Windows XP is that once you boot up out of Hibernate, the game doesn’t seem to restore itself and you’re forced to kill the task and reload the game. Not pretty. So I fired up Visual Studio 2008 quickly and just wrote a simple app that displays a warning message. I set it’s properties to pop up over everything else and then configured it as follows: 
-
On the Display Properties screen, click the “Screen Saver” tab. -
One the Screen Saver tab, click the “Power” button. 
-
On the Power Options Properties window, click the “Alarms” tab. -
On the Alarms Tab, click the “Alarm Action” button. 
-
On the Low Battery Alarm Program window, click the “OK” button. -
On the Low Battery Alarm Actions window, click the “OK” button. -
On the Power Options Properties window, click the “OK” button. -
On the Display Properties window, click the “OK” button. Tired of clicking “OK” yet? OK, now go ahead and go play your game. When the battery low action triggers, this is what you’ll get: 
The popup message will actually occur even before the Windows system message as seen below. 
Hope you enjoy the utility. Later
C |
|
|
|
|