I upgraded the Image Widget plugin for WordPress on one of my sites and, as I’d gotten into the habit of, I didn’t back everything up before updating, oops! For some reason the upgrade bombed and I was greeted with the dreaded 500 error when trying to load the site. From past experience I knew that the plugins needed to be disabled so that I could administer the site so I followed the directions on this site (under “Updated Method”). The site would then load and I then reactivated all the plugins except that the Image Widget died with a fatal error of :
Warning: require_once(/var/www/website/wp-content/plugins/image-widget/freemius/includes/sdk/Freemius.php): failed to open stream: No such file or directory in /var/www/website/wp-content/plugins/image-widget/freemius/includes/class-fs-api.php on line 85
I tried in vane to try and track down the offending code but had no luck; and it doesn’t help that no one seems to own up to using this Freemius program. What was quite aggravating is that there is no “freemius” directory anywhere, but this turned into part of the solution: why don’t I just recreate it and make everything null? So I made the folder structure and required files:
There seems to be lots of hate for Sage over this, but I guess there wasn’t much of a market for an inferior point-of-sale product that tied into an inferior accounting package (not that I’ve ever heard good things said about Sage 50 which seems to survive based on inertia).
I had a server running with the 32 version of Server 2008 that I needed to migrate over to the 64 bit version of Windows Server. The server hosted both our Active Directory Rights Management Server (AD RMS) along with our Microsoft Certificate Server (CA). I had tried porting it years ago but was unable to get the certificate services to start. As part of the process I had already ported the RMS DB to SQL. I decided to give it another try and have some tips in no particular order:
First I needed to get certificate services running. I started by turning off the old server, installing a new Windows Server 2008 64 bit version with the same name. I then installed certificate services role using the instructions here. However when I tried to follow the instructions for migrating the database I was getting errors like ‘jet_errmissinglogfile’ or sector size mismatch. The fix was to copy over a ‘clean’ version of the database from the old server (a copy taken while Certificate Services is stopped), deleting all the files but the database (edb) and starting the service. (I had also previously imported the original ‘config’ registry entries per the earlier referenced instructions).
AD RMS proved a bit more tricky. First I installed 64 bit version of SQL Express which matched the instance name of the old server. HOWEVER, the better move would have been to uninstall AD RMS from the old server first. In this case I had to use ASDI edit to remove the ‘SCP’ section from AD (under Configruation->Services->RightsManagementServices). I was then able to install and restore my settings (DB and registry). Be sure to check the functionality of documents secured with RMS and the admin console though. Of special note is that after upgrading to Server 2012 I needed to run the ‘Update-ADRMS’ utility; it will NOT work right without doing this!
Migrating from SharePoint 2010 Foundation to SharePoint 2013 Foundation/Services/etc.
I followed the well illustrated instructions here, but several key points were missing. Perhaps a lot of the grief was caused by the fact that I didn’t want the SharePoint application pool to be run by Local System/Network Service/Administrator.
First the security in 2013 uses ‘Claims Based’ security (the exact details of which I am not completely clear on, but anyway) while 2010 security is referred to as ‘Classic’. On this page (step 6) they detail how to setup a site with classic security within 2013, though my impression is that there is no benefit to ‘upgrading’ when doing this (you would just make the new site that you want and attach your content database that was brought over using the steps from the first article and it could be left there I suppose).
In order to upgrade your restored content to the new security model I followed the proper steps in the same article that has the tip on how to make a ‘classic security’ site. After that the plot thickens. It will be necessary to modify the web.config files for the site, the admin site, and the security tokens “site”. I used this article as a reference (step #3), but it is missing pieces as well. Be sure to make backups of the originals as a mistake can render the entire installation inaccessible! An important note is that although I basically copied the tags from the source website over to the admin and security tokens site, it’s important not to put any switches in the ‘<roleManager>’ in either of those. Within that article are also steps on adding ‘SPN’s so that the application pool account can run authentications (otherwise watch out for KDC_ERR_S_PRINCIPAL_UNKNOWN/0xc0000035 errors); as well, this article points out the delegation steps required in setting up the SPNs.
I believe at this point the site was working enough that I was getting the “Sorry, this site hasn’t been shared with you.” error when accessing the site (though from somewhere it noted that you should be able to pull up the local settings under “domain.com/_layouts/15/settings.aspx”. Just a few final things needed to be done. First forms authentication had to be disabled within the central administrator and IIS. As well I needed to follow the steps here in order to make sure that the application uses the …SPN, or something. Lastly I was getting an error where my application pool account did not have ‘local activation’ rights over an app (the CLSID is for the IIS WAMREG admin Service). In order to remedy this I had to follow the instructions here so that I could change the permissions for IIS WAMREG admin Service.
Extra credit: I used this page to mock up a forms authentication, but further study is needed.
So this has happened to me twice and I had forgotten how to fix (‘fix’) it from before so I’m writing it down here for when I inevitably forget again.
The symptom is that the user’s address autofill/AutoComplete within Outlook stops working. Since we run on a later version of Exchange this means that the autofill information that is stored on the server is corrupt (this post applies specifically to Outlook 2010/Exchange 2013). As far as I can tell the settings on the server are gone so the information has to be reconstructed, which for the user, is better than nothing. To do so I follow these easy steps:
If you want a backup of the corrupt information, you can follow the steps here or backup the ‘DAT’ files (outlined in this post, though there seems to be a consensus that this won’t do the trick on Exchange where these files are always ‘pushed’ and never ‘pulled’)*.
Many, many years ago I had a domain controller installed on a rather naughty IBM server. This server, as it turned out later, had some bad firmware on the drives which would cause occasional system oddities such as blue screening, hanging on boot, etc. I let it go for too long, but the issues were vague and infrequent; many a techie know the rut one can get into when it’s safer to leave well enough alone. That line of thinking is always a catch-22 and the server’s issues finally came to a head when it crashed the right files and my domain controller no longer thought that it was a domain controller.
What about backups you say? Well we had our handy-dandy untested disaster recovery backup from Arcserve, which turned out to require a special boot disk that needed to be made from the server in question before the disaster (this later turned out to be bogus anyway as I later found that even under the best lab circumstances I couldn’t get their worthless product to work). I was in a pinch so I called Microsoft support and somehow, over the course of the night, they were able to get the trashed Active Directory operational again. The call spanned between two shifts so the guy I talked to at the end of the call was not the same one from the beginning.
Compare that experience to my recent experience with my Exchange 2013 setup where, it appears, no one in the eastern hemisphere was given proper training on the issues that this product is prone to having. No one calls back in time, despite the use of cut-rate help, and if your support rep has an end of shift they may abadon you until the next morning. Don’t bother with web/phone support unless you’ve exhausted the list below.
First and foremost, Exchange 2013 as released was a beta product. Cumulative update 1, made it seem like it was usable, but please be sure to install CU2 if you want a product that comes close to behaving! Before installing CU2 the ‘RPC over HTTP’ function was sketchy and I would get prompted for authentication when making a new profile, external users would work while internal ones would not, and running tests would result in ‘500 http’ web server errors in OWA and ‘X-CasErrorCode: ServerLocatorError’ when running the connectivity tester.
After installing cumulative update 2 on two different servers, it failed to start both the transport service and the frontend transport service (while making sure to start ‘manual’ processes that we don’t use like unified messaging).
The new Exchange control panel is a marvel to behold, and crap at the same time (much like Microsoft’s whole product portfolio at this point in time). If everything works it’s great, but when it comes time to set ‘internaluri’ and whatnot to the virtual directories it’s best to get familiar with the get/set functions for these in Powershell.
Please make a note that the ‘Microsoft Exchange Service Host’ service has a nasty habit of resetting/changing the RPC folder settings in IIS. On one server it would change the backend RPC to point to the frontend folder and on another it would turn off all the SSL on the RPC folders. Why does it do this? No one knows, though Microsoft did tell me that this can be effectively managed if you go to the registry key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator’ and set ‘PeriodicPollingMinutes’ to zero. However, if the server reboots, be sure to double check these settings again.
Amateur mistake, but remember when migrating mailboxes keep in mind that it will eat up double the disk space of the source mailboxes until a backup can roll the logs off. Please note that backing up with DPM 2010 apparently does not count as a backup. (Also note that, for whatever reason, mailboxes get a 5-10% size boost when going from Exchange 2010 to 2013).
Setup will make the proper ‘receive’ connectors, but not the send connector. When making it through the Exchange control panel, I had to uncheck ‘‘ so that my send connector would work properly.
Another note is that within IIS, if you are not able to access Exchange properly through Outlook (but Outlook Web Access works), then it might also be that you are missing the ‘Negotiate’ provider for Windows Authentication. Just add/check it by right clicking on Windows Authentication under the virtual directories->Authentication applet and clicking advanced.
One site had issues with Outlook hanging on the new message notification and a general slowness in trying to do anything else. Were it not for the niggling issues from the migration I might have turned on to the culprit sooner: Kaspersky.
Of course I wonder how many places still run their single Exchange server in-house. I’d imagine that it’s getting to be a pretty lonely existence. If this is your situation: migrating a single Exchange 2007/2010 server to Exchange 2013, I should point out an issue with the SSL certificate. Chances are if you have one Exchange server, you have one, simple commercial SSL certificate as well, though even if you cheap out and use self-signing this issue still might apply. The issue is that once the users are migrated, and you then migrate the certificate, the Outlook profiles will need to be rebuilt – for every user. I am guessing that there are at least two possible work-arounds, though I haven’t tested them. One is to get a certificate with a different name, this way Outlook knows that it’s a different server and to re-do it’s security settings. Another idea is that it might be possible to migrate everyone to the new server, let Outlook catch the settings change (this part does work) and then move the certificate later (sketchy on how Outlook will behave here). The main issue with this is remote e-mail support since the old server cannot proxy to the new one (I believe?). Otherwise, without changing the profiles, end users will just get logon/credential prompts and not be able to access their e-mail.