When using the interactive Windows Certificates snap-in, a 3rd very important cert target store type can be selected:
One can select "my user account", "computer account" and "service account" as target for certificates.

xCertificateImport currently seems to only support 2 target store types:
Location: 'LocalMachine' or 'CurrentUser'

As an admin it would be very cool to be able to also use xCertificateImport to also manage service-related certificates, as there are otherwise no PowerShell means to do so and the GUI cert tool is a PITA, as its not scriptable. And there are Microsoft own services out there that needs such certificates. For example Microsoft AD LDS uses certificates stored in the service accounts section for SSL/TLS certificates. e.g. in:
[HKLM\SOFTWARE\Microsoft\Cryptography\Services\ADAMinst1\SystemCertificates\My\Certificates]
There seems to be no means to use xCertificateImport to manage that path
(Referring to https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs.85).aspx#CERTSYSTEMSTORESERVICES)

(the old fashioned state based Powershell Cert commands seem to have the same deficits, but why not do it right in this command - that would probably need a 3rd parameter Location="service" and a further Servicename="...." parameter)

Windows supports two password APIs, change and reset. The change API honors password history, preventing users from re-using recent previous passwords. The reset API ignores password history and allows an administrator or e.g. help desk, to re-use a recent previous password. Add an option in Active Directory to force the reset API to also honor password history. The default should be that this option is disabled, an administrator CAN use a recent password, so it matches expected / current behavior. For Active Directory, this option should be available in the default domain policy and also in each password settings object for granular password policy.

Thanks

Steven

Create a built-in group "Developers" on Windows Server (and domain controllers) and restrict the activity of those users to compile, debug and run their applications. If the developers computer gets compromised then the damage is limited. Unfortunately the effort to restrict "developer" accounts is too error prone.

Following the convention of least privilege, application developers need not be a full blown administrators on their development machines. For example, they don't need to mange users, groups, memberships or even be able to make changes that effect everyone on the host. They do need the ability to compile and debug their software.

Similar to Azure, create roles (aka groups), that would better control what developers can do.

The whole CA management interface feels so overdue. i know the whole certificate thing wasnt built by microsoft and it pushed into the marked real fast (relatively speaking) so a solution had to be realized quick. The whole topic is very clumsy and involves so many manual steps that it gives lots of admins around the globe headaches. It is also very hard to learn and master due to the wrong tools i think.

The certification management in exchange control panel 2013 seems a step in the right direction. I cant really tell you what to do, but im sure that if the right guys at microsoft sit together, think and talk about this, something great comes out of it.

Dont get me wrong, this really isnt a Microsoft problem here. its a industry wide problem. But Microsoft could bring out a completely revised certification management (client and server) with their next version of windows and roll the dice to change the whole industry here. Just as other competitors have done with multitouch for example.

All throughout windows, it is very common to have to enter and save passwords, and, what's worse, when a password is changed, you have to try to remember everywhere that it was set.

A good example is inside of an Active Directory environment where you have Services that run under a specific user. If you change the user's password, then you have to go to each server and update the password.

I suggest that features like this be re-architected to take advantage of OAuth (or a similar technology) very similar to how Facebook and Twitter let you Authorize Apps.. I should be able to tell a service to "Run As" a user, enter that user's credentials once, and then have an OAuth relationship created between that user and that service. This would have a few important advantages:
1. Saved passwords become a thing of the past.
2. Greater stability for services when implementing best-practices with passwords.
3. Ability to see all "Authorizations" that a user has granted.