What's happening is that the WinLogon service, the service that handles the logged in environment for RDP and local logins, is getting hung on shutdown for some reason. Could be some weird locking is going on that's preventing something critical from shutting down, or maybe the registry is still open somewhere. When you kill the winlogon service, it breaks the logjam so the reboot can move apace.
This will leave Event Log traces! In the Application Log, right before the reboot there will probably be some events describing why the machine couldn't go down just then.
The reason shutdown /m \\machine /r /f /t: 0 fails on you with that particular error message is that if the reboot has progressed past a certain point, it'll reject further reboot requests. The pskill method works because it isn't asking the machine to reboot, it's just knocking loose the process that's gumming up the reboot-in-progress.
I won't speak to WHEN it will happen, since the date has fluctuated...but to answer your questions and help make this question a canonical for this topic that is sure to pop up a lot...
So I assume that means there will be windows update patches available
until that date?
MS will continue to release new patches/updates for XP until that date. Existing patches/updates will continue to be available afterwards. See the next answer for more details.
What happens after that, no patches at all?
Microsoft will still allow you to update XP with any patches it has released up to the date that support officially stops.
"This means that after the 8th April 2014, you'll still be able to use Windows Update to download all existing security patches.
This is important, as if you re-install Windows XP, you should still apply all of the existing patches in order to make the base operating system as secure as it should be."(1)
The important thing here is to at least get all your existing XP computers patched properly, which should have been happening all along. Don't get hacked with an exploit that came out 2 years ago!
if you are willing to pony up the money, Microsoft does offer "CUSTOM SUPPORT" to companies/governments/etc. willing to pay for it. The price isn't set in stone though, and is pretty exorbitant:
"Microsoft understands that local laws, market conditions, and support requirements differ around the world and differ by industry sector. Therefore, Microsoft offers custom support relationships that go beyond the Extended Support phase. These custom support relationships may include assisted support and hotfix support, and may extend beyond 10 years from the date a product becomes generally available. Strategic Microsoft partners may also offer support beyond the Extended Support phase. Customers and partners can contact their account team or their local Microsoft representative for more information."2
That means the potential for hacks, virus, etc. are greatly increased?
Greatly increased isn't a hard/fast metric. To say it will increase 10%, 20%, 150%, is hard to say. The potential is definitely there for exploits to surface for XP that MS could have the ability to patch but won't after EOL.
However, there are ways to lower the threat risk and help ensure you are safe.(1)
- Make sure you have a good antivirus program, hopefully one with a decent malware scanner as well. The choices are numerous, so I'll leave that choice up to you.
- Make sure all your software is patched and up to date. It can easily be a software exploit and not an OS exploit that allows for viruses/hacks to occur. Realize though that 3rd party software often won't be patched like an OS will, and worse they will often come back and say "you're still on XP? Our current version isn't compatible with XP now, you'll need to buy an upgrade."
- Secure your web browsing as much as possible. This means knowing what sites you are accessing, using web content filtering if possible, using an A/V program that helps scan for issues while you are browsing, and disabling Java and other scripts from running if possible. Switch to Chrome or Firefox if possible, since IE for XP is dated at this point.
- Be sure you aren't running with an administrative level account. This is good practice regardless of OS, but especially so after losing the ability to have security updates/patches for any new threats that arise.
- Stop using Office 2003 and Outlook Express, which also will no longer be receiving updates/patches.
- Upgrade to Windows 7 and use XP Mode for those stingy old apps that refuse to be updated.
Other choices independent of XP that are good security practices regardless of OS also prevail here:
- Use both the desktop/client firewall and a "real" firewall(s) within your network, especially at the edge.
- Use an IPS/IDS if possible
- Keep detailed logs of network activity. Look for suspicious activity ESPECIALLY once an exploit becomes mainstream and starts making tech and news headlines.
- Prevent installs of 3rd party software IT doesn't trust. Don't allow your users to install anything they desire (again better stated than implemented).
- Keep your servers secure as possible. While an infected XP PC is bad, and hundreds of infected XP machines is worse...don't make it paramount by getting your servers infected/exploited by not securing them properly from virus propagation, etc.
- Make sure your wireless and wired network is secure. This means not letting that employee bring in their "personal laptop" running XP with no service packs or a/v onto the network. If you are allowing such things, then all of the above is worthless. Same goes for VPN connectivity from home, USB sticks, etc. Make sure you know what you are letting onto the network.
FINALLY, is there an answer to really make sure you sleep well at night? Sure, it's called "UPGRADE FROM XP". While that may be a daunting task/project to undertake, realize that you aren't alone in this and that everyone else that has waited this long is undertaking the same project. Work through the issues specific to your company, draw up a plan of attack, and implement. There will obviously be costs involved as well as politics and user/culture paradigms, and if management simply decides to hold off even longer there's not much IT can do to force their hand other than list out why it is a bad idea to continue putting it off. There isn't a "one size fits all" approach here and if your company is still running a majority of XP workstations without a migration project already underway then it is likely there hasn't been much regards in terms of lifecycles/best practices/etc. regardless.
FURTHER READING:
Besides the existing footnote links I provided after the italicized quotes above...here are some links and info to help you make the decisions and transitions:
https://www.microsoft.com/en-us/windows/enterprise/end-of-support.aspx
http://windows.microsoft.com/en-us/windows/security-essentials-download?os=winxp&arch=other
http://windows.microsoft.com/en-us/windows/help/what-does-end-of-support-mean
http://www.microsoft.com/windows/en-us/xp/top-questions.aspx
http://technet.microsoft.com/en-us/magazine/ee851564.aspx
http://technet.microsoft.com/en-us/windows/bb264763.aspx
http://technet.microsoft.com/en-us/windows/hh706147.aspx
Best Answer
Windows update will not permit you to perform installs over Powershell Remote sessions since it does not allow any remote authentication token. This does not only affect the running of routine updates but also the installation of windows features via dism and servermanager as well as many Microsoft MSIs. Looks like Windows Management 4 is among them. The best way around this is to create a scheduled task to perform this on the remote machine. As noted above PSEXEC works too provided provided file access ports are open and, if you are not in a domain environment, you have enabled LocalAccountTokenFilterPolicy.
I recently added this functionality to Boxstarter.org as of version 2.0. With this you can install chocolatey packages, windows features or windows updates remotely and Boxstarter will create a scheduled task from the remote powershell session. It will stream the output back to your session so it looks and feels like it is running from inside the session. See http://boxstarter.org/InstallingPackages#RemoteInstallations for details.
In Short the command looks like: