When I was ready to shut down for the night... I noticed some settings that would allow me to put restrictions on its use. I thought, "Great! Now I can lock my kids out of downloading whatever random application they go looking for, since this Touch is linked to my iTunes account; which is linked to my payment information."
So I turned on the restriction for installing apps; thinking it would only stop someone that was using my iTouch on a Wi-Fi network from installing applications from the App Store. I turned off my iPod and slept for the night.
The next day I fired up iTunes with my trusty Touch connected to the USB on my laptop. I downloaded one more app from iTunes and was going to sync with my Touch.
I clicked on the Applications tab in iTunes for my iPod Touch and all the controls were greyed out (disabled.)
It turns out you need to lift/remove the restriction on your iPod in order to enable iTunes to install an app on it too.
To enable/disable the restriction, navigate to:
Settings >> General >> Restrictions >> Installing Apps
EDIT: Make sure you sync your device after making the change... some have still had the option greyed out after making the change.
Annoying, but safe... and now you know...
After determining that multiple people (both connected via VPN and on the local network at work) had the same results, we started trying to find out what was up. Rebooting the computer did not solve it.
After much pain and suffering, we discovered this message in the event viewer (several times):
\SystemRoot\System32\RDPDD.dll failed to load
Doing a search on the internet quickly (and thankfully) brought me to Brad Rutkowski's Blog which had an article about the \SystemRoot\System32\RDPDD.dll failed to load error.
The article suggests several fixes. I've only confirmed the "D" option which is a registry tweak that increases the size of the session image space. It worked like a champ and I'm now able to get back into my work machine from home.
The only things I remember doing recently were a slew of Windows Updates from around 13 August 2008 and I think I update the nVidia drivers a week or so before. (Incidentally I hadn't tried remoting in since those two updates were done.)
For convenience, I've repeated the registry tweak fix here:
Please see the blog post on Brad's site for the rest of the options if this doesn't work for you.
D) A solution found at http://forums.nvidia.com/index.php?showtopic=67147&hl=remote%20desktop&st=60 worked for me (and others.)
It's a registry fix that increases the size of the session image space. Add the following key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
Where 00000020 is hex for 32
In any case the event was a red herring and was just a generic error being bubbled up from Win32k.sys..
Thanks Brad for providing that information!
Please tell us about your experiences with this problem...
Rebooting, as is often the case, resets things and makes them right again where it will come back up in Normal Mode, but that's not an acceptable solution when you have several other windows open and you're not ready to shut them all down to reboot just to fix Outlook dorkness.
What I found was that the problem had to do with the fact that I had a Windows Mobile device sometimes hooked up with my machine using ActiveSync. This causes another non-GUI instance of OUTLOOK.exe to be running in your task manager so it can keep things in sync.
When this is the case... closing down the GUI only closes down the one instane of Outlook, leaving the one the mobile device opened still running. This keeps Outlook from resetting it's mode the next time you launch the GUI.
Open Task Manager by either right-clicking the taskbar and selecting "Task Manager"; or by hitting Ctrl-Alt-Delete and selecting the "Task Manager" button.
When in Task Manager, click the "Processes" tab and click the "Image Name" column header to sort them alphabetically (this will get all instances of Outlook together.) Highlight each instance, one-at-a-time, and click "End Process."
Once they're all cleared out, you'll be able to re-launch the Outlook GUI and have it appear in "Normal Mode" again, without requiring a reboot of the computer.
I hope this helps someone, and I'm not positive if it works on other versions of Outlook; but I'd have to imagine it does... please chime in with your comments if you have had similar situations; and/or know if this solution works for other versions of Outlook.
I bought an Antec computer case a while back and the 120mm fan on the back was mounted with these cool plastic looking things instead of the normal fat metal screws with threads so thick you can't easily screw them into the case without a power drill. The "plastic looking things" are, in fact, referred to by Antec as "Silicone Fan Grommets."
Needless to say, I was opting for the Grommets as I hate messing with those fat metal screws; and I just really like the word Grommet.
Luckily when my fan died, the hardware kit that came with my case contained 4 extra Grommets I used on the replacement. I also noticed an internal mounting spot for another 120mm fan to help extract heat from the hard drive bays. I decided I wanted to mount a fan there as well, but knew I'd have to have Grommets there or I'd be in big trouble trying to get the screws to mount in that area.
I decided to try Googling for them; but realized I had no clue what they were called. I started with the phrase: 'antec fan mount screws' (without quotes) in hopes of finding them as a "related item."
I quickly gave up and headed to the official Antec website. They have a "Spare Parts" link that will allow you to buy the not-so-easy-to-find parts. It was there (and thank heaven most items have images next to them) that I found the Grommets. I never would have found that name on my own.
Searching for Grommets on the search engines after I discovered their "official" name didn't turn up many other options for where to purchase them.
So if you're looking for them, I'd recommend Antec. When I purchased mine, they cost $6.45 for a set of 4, but the shipping was free; so that was nice. If any of you out there know of more places to purchase Grommets, please leave a comment with a link so we can all be enlightened on where to find these very useful fan mounting tools.
You know what they say, "by small things shall great things come to pass." Since these are meant to help noise reduction with the fans, I'd consider that a great thing.
I correctly set the PHPIniDir setting in httpd.conf and set the correct extension_dir. I confirmed so by bringing up a page with phpinfo() called and it was showing my other extensions loaded. I'd comment one out (like php_gd2.dll) then restart Apache and refresh the phpinfo() page. The gd information disappeared, so I knew the settings were correct.
After a bunch of searching, I finally found a newsgroup post that pointed me in the right direction. there is another dll called libmysql.dll that comes with PHP (but is in the root PHP folder, NOT the ext folder.)
Both php_mysql.dll and php_mysqli.dll depend on this DLL. The fix was to copy this file to the WINDOWS directory. Once I did that, I restarted Apache and refreshed my phpinfo() page. There they were. Huzzah!
In my searching it seems people may run into this issue because of a few different things; so I'm publishing what I think is a good plan of attack for discovering what might be the problem when you can't get the MySQL extensions to load in PHP:
- Confirm the extension_dir setting in php.ini is set correctly (trailing slash is required on Windows; I'm not sure about other operating systems. Example: C:/php/ext/)
- Confirm the files exist in your extensions directory and are spelled correctly.
- Ensure libmysql.dll is copied from the root PHP directory to the Windows directory. This is extremely important if you've upgraded PHP as well and have an older libmysql.dll in the Windows directory that may not work with the newer PHP code. Make sure the current PHP version's libmysql.dll is copied to the Windows directory.
If you have discovered anything I may have missed that would help others that also run into this issue; please leave your feedback here.
Most have replied that the cause of the problem is that the directory in question doesn't have the right options set on it and they go into detail explaining that they need to add things like:
to their httpd.conf for that directory.
They're accurate, but their description isn't full enough to solve the problem. What I've found is that there are two things that need to be configured first off in httpd.conf to ensure success with your specific "DocumentRoot".
In the default httpd.conf file are two lines (with comments) that go hand-in-hand:
(using a default installation of Apache on Windows XP as an example.)
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs"
... and the other section (contents excluded) as follows ...
# This should be changed to whatever you set DocumentRoot to.
In-between these two sections is a section that sets ALL directories to a "default" set of VERY restrictive features.
Deny from all
The problem I've found (and I've made this mistake several times myself; so I'm documenting it here to hopefully help someone else fix the same mistake that causes the Forbidden message...) is that people change the DocumentRoot setting to where they want the default folder for serving up documents to be... but don't change the second section that matches the original DocumentRoot's path.
The reason the forbidden error happens is because that section inbetween restricts ALL directories, and the section after (that originally has the old DocumentRoot path) lifts the restrictions... but since it's still pointing to the old DocumentRoot and not the one you've changed to... it's lifted the restrictions on the wrong path; leaving your REAL DocumentRoot restricted and therefore causing the Forbidden message.
I hope this helps someone save hours of frustration trying to find out where to add the Overide +FollowSymLinks, etc... when it's already done for you in the original httpd.conf, you just need match the paths in that Directory section with your DocumentRoot setting.
NOTE: I'm not the ultimate guru on httpd.conf... there may be more secure ways to handle this and I'd love for someone to leave comments here on better ways. I just know this way works to get you up and running fast to solve the Forbidden problem.
Apache rocks. Happy HTTPing!