I have a web server running OS "Windows 2008 R2 - 64 bit" that hosts several websites for my clients (small companies). Since June 2013 "Windows Update" automatic updates has been turned off. I was told to turn automatic updates off as it can cause the server to crash, which would obviously affect my clients.
My concern is obviously that when I ran Windows Update today I see there are 130 important updates, most of which start with "Security Update...", others just start "Update...".
What is the best practice regarding Windows Update, and particularly turning on Automatic Updates, for a production web server?
The web server runs IIS 7 with SQL Server 2008 R2. The sites are all ASP.NET sites, some Web Forms, some Mvc.
Hopefully this isn't too generic a question. I'm obviously afraid that I might have to install these updates and risk bringing the server down.
Probably better asked on serverfault
Start with this question over there:
To update or not to update
https://serverfault.com/questions/134324/to-update-or-to-not-update
Related
We’re running TFS 2013 Update 1 and I’m planning an upgrade to TFS 2015 Update 1.
We have both SharePoint and Reporting Services installed and configured for TFS that I like to remove, because nobody ever uses them.
So, do I simply uncheck both Reporting and SharePoint during the TFS 2015 upgrade wizard. Is this the best way to do it?
Or, do I un-configure Sharepoint and Reporting Services first from our TFS 2013 installation? If so, what are the steps to do so?
Environment:
Server computer A:
Application tier for TFS 2013 Update 1
Data tier: SQL Server 2012 SP 1 for the TFS databases, and Reporting Services databases
Sharepoint services (only for TFS)
Server computer B:
SQL Server 2008 R2 hosting the SharePoint databases.
You can do either.
I'd probably uninstall/disable first if you're really sure you don't want them in the future (check with all the teams that they're not storing docs in SharePoint as they will lose them). That way the backup will be smaller/faster when you backup before you upgrade (Make sure you take a backup!!).
It's simple enough to do, just fire up the TFS Administration Console.
Select Reporting, Edit (this will stop the jobs) and uncheck "Use Reporting". Click OK.
For SharePoint, click SharePoint Web Applications and under the top section, click Modify against your server connection and choose Remove.
Make sure you take a new backup at this stage and then you can start the upgrade.
Some things to consider:
Are you sure you want to do this in-place? You could clone the server to new hardware and test the upgrade first or perform a migration upgrade. It means less downtime in the event of something going pear shaped.
If your collection(s) are large, this is likely going to take a long time. The 2015 upgrade seems to be slower than previous upgrades due to all the schema changes.
Are you sticking with a single server? That's fine, but you won't need server B for SharePoint so you could move to a dual server TFS install if capacity is a problem (You'd need to upgrade the SQL version on server B to act as a data tier though)
I'm a couple years late, but this still popped up in a search result so worth mentioning - use cmd prompt to do this:
Navigate to %programfiles%\Microsoft Team Foundation Server %#%\Tools\, and type TfsConfig.exe setup /uninstall:SharePointExtensions . This will "unconfigure" the feature in your App Tier.
I have fairly large legacy (read only) VSS 8 database that is currently sitting on a windows 2003 server.
As part of an infrastructure consolidation I am being asked to move it onto a new Windows 2012 server. I can't find any notes on whether or not VSS8 will run on 2012; before I even attempt this do you know of any issues running VSS on Windows 2012?
Is it easier to flip the old server to a VM and keep it for posterity and those rare occasions we want to know what someone did in the naughties?
The database itself is merely a fileshare, so you don't have to install the accelerator if you don't want to/are unable to.
In the weeks since asking have deploying VSS2005 (with the runtime available on the server) onto Windows 2012 enterprise. The applications install with a warning about versions but they run fine; including the admin tools for users and checking the consistency of the databases. The end user side all works well too.
Need to see if ColdFusion 5 will run on MS Server 2008 R2.
On a client's site that has ColdFusion 5(yes 5) and wants to move it to a MS Server with 2008 R2 and IIs 7.5 on it. The one app that is on it is going away as is all ColdFusion. So they do not want to invest in an upgrade. Simply not an option for them and they have made it clear.
2008 R2 Issues: CF 5 being 32-bit doesn't install for me. Is there a way to make this happen?
IIS 7.5 I've read articles that CF 5 can be run on IIS 7.5 with compatibility mode turned on. I don't think this will be the big hurdle.
The alternative is to keep in on the server it's on but for reasons this is the last alternative.
So for the most part I am looking for advise on running CF 5 on MS Server 2008 R2.
Thank you!
I don't have Windows Server 2008 to hand, but I was able to install ColdFusion 5 on Windows 7 64-bit with very little problem, so you should just go ahead and give it a go (which is always a reasonable approach in these situations).
I have fully-documented my install experience on my blog for you (in case it's any help). It's too long to post here.
Just thinking, Scott. If the reason to not pay for an upgrade to a still-supported (and secure, and not unstable) version of ColdFusion is down to the licensing costs, have you considered Railo instead of ColdFusion? The software itself is free, but obviously you'd have to expect a bit of recoding for CFML which is no longer valid. There's not much of this, but more recent CFML implementations are - on the whole - less forgiving of dodgy code than old versions.
The benefit of taking this approach is that you'd be running software that is still maintained, and is up-to-date as far as security issues go. I think it's borderline negligent to be running outward-facing software which is so out of date, if I'm honest. Are your clients aware of the potential risks here?
Perhaps it's not an option, but maybe it is, so I thought I'd suggest it.
I am specing out new development workstations for my team and I am running into a conflict. I am a developer and I want Windows Server 2008 R2 because that is what our production servers are running. The IT guys want to give us Windows 7 because that is where they have tested all their infrastructure.
My question is this: is there enough of a difference between the two to push for 2008 R2? I know MSFT has crippled IIS in previous versions of Windows unless it was the server edition so I am skeptical about Win7 giving me what we need.
You can use Windows 7 for your development machines and have one Windows Server 2008 R2 for UAT deployments. This way you can have the best of both worlds. IT will be happy that you are all running Windows 7 and you will be happy that you're able to test your application in windows server 2008.
This question answer might be helpful.
Differences between Windows 7 and Windows Server 2008 R2
Your IT guys are correct aside from licensing issues such cost as Office without workstation on OpenValue, OpenSelect etc.. (remember they are packaged together) etc.. there are hardware issues and compatibility with future software.
There is no way you need 2008 R2 Server, do you want to work in the data center too? or have a full copy of the live database? You should have a CI server though that represents the live environment , the IT guys should provide this for you - probably as a VM.
My development machine is running Windows XP SP2 (and IIS 5.1 by implication).
Until recently our deployment environment was based around Windows Server 2003 (and therefore IIS 6.0).
We are about to move to Windows Server 2008 (and therefore IIS 7.0) for a new project.
Our projects use ASP.NET MVC and WCF Services.
Are there any key reasons for us to upgrade our development machines to run Windows Server 2008 (or possibly Vista, since this also comes with IIS 7.0)?
I would say it's in your best interest to upgrade your development machines to emulate as much of the production environment as possible within your means and resources. Otherwise you may fall into traps you're completely unaware of just by deploying an application from your development machine to the server's environment, which may pertain to differing versions of IIS, the version of .NET framework each machine is running, or just the way the code is compiled or executed at runtime.
Especially since IIS 7 has been vastly upgraded since IIS 5.1, why shouldn't you work closer with it's current functionality while developing before you missing out on some great opportunities? To really know what to expect from an application in production, develop it under the same circumstances.
Edit/Added: This link may help you see at least one significant example of how differing versions can affect your project.
I would recommend that you develop against the same major build as you intend to deploy on. That said, this leaves you with a few options. First, you could build against your local IIS installation (as it appears you currently do). That means that all of your boxes should likely be upgraded to Windows Vista or Windows 2008 Server (or Windows 7 as it is running IIS 7.5). Your second option is to deploy to a remote machine. It is entirely possible to deploy your application to a remote test machine running IIS 7 and remotely debug as well. The problem is that if you have more than one developer working on the remote site, it becomes problematic. IIS can handle the remote debugging on different webs for different developers, but depending on your architecture and configuration, you may still be sharing resources between instances of test web applications.You could occasionally deadlock each other. The only benefit is that you don't have to buy licenses for all of your machines (and potentially upgrade hardware to support the OS upgrade). However, I think that would be short-sighted. The loss of developer productivity wouldn't be worth it, IMHO.
There are major changes between IIS 5.1 and IIS 7.x. The changes to the architecture, such as the integrated pipeline, can result in drastically different behavior and compatibility issues. I think you will find that IIS 7 far more developer-friendly. The introduction of things such as failed request tracing, extended logging, and enhanced error pages alone make it much easier to track down errors in your application. In that regard, the upgrade is well worth it.