We have run into an issue where there are corresponding event viewer entries that show something regarding Security-SPP at the same time the windowsupdate.log file started writing its checks for automatic updates.
Prior to that entry, the update settings were set by Group Policy. My question: Is it possible for Security-SPP to re-enable automatic updates and/or override what has been determined for group policy?
I have been informed by a number of individuals that the windows update service must have its startup type set to "DISABLE" or it runs the risk of getting started by another service such as SPP or other AV programs.
It is a possible way to protect the system in the case of a zero day or other important update.
Related
My company's application experienced database connection issues this morning resulting in me having to failover to our secondary database. Within our Azure App Services, this was an easy step of changing the connection string in the configuration, however I could not find an easy way of changing these settings on our Service Fabric services without redeploying.
I'm considering options to allow failover at runtime for these services to a secondary database but don't know what the 'best practices' would be. A couple options I have:
I could create a dns entry for our database server that i manage and then just switch that to the new server name when I need to fail over.
I could have some sort of rest api to call on my app services that would return whether or not to go to the secondary database.
Any other ideas? I'd like to make failover to the secondary as seamless as possible so it can be done quickly.
Have you considered putting both your primary and secondary database connection strings into your application's config and writing some code that automatically switches between them if it detects a problem? Both of the options you presented puts a human in the path, which means your users are going to experience downtime until the human fixes the problem (maybe the human is asleep, or on vacation, or on vacation and asleep).
In Service Fabric, Application (and system) upgrades are always rolling upgrades. Rolling upgrades have the advantage of preventing global outages. For example, suppose at some point you updated your config with the wrong connection string. A global config change might be quick and easy, but now you have a global outage and some upset customers. A rolling upgrade would have caught the error in the first upgrade domain and then rolled back, so only a fraction of your application would have been affected.
You can do a config-only rolling upgrade. This is where you make a change to your config package and then create a differential upgrade package so that only the config changes go out and your service process doesn't have to restart.
Just to post an update to my issue here. SQL Azure now has automatic failover groups. This is described here
When I manually provision a system (select the system, distro tree, etc) and click on Provision, I do not see a new job created. I get the impression that nothing is happening.
I am using Beaker 19.0.
This was one of the changes in Beaker 19.0. A manual provision doesn't create a job any more. To see what is happening, you have to hop on to the system's serial console either physically if possible or via using the console program provided the required infrastructure is in place.
To learn more about the change see the relevant release note entry.
We want to enforce at minimum a PIN and an inactivity timeout on our Windows Store App.
The Exchange Active Sync (EAS) policy API looks like the right thing to use but it should be used with much caution.
You can either check for compliance or enforce compliance
MaxInactivityTimeLockValue should work for the minimum time before the screen locks
The trouble is that the check RequestedPolicy.CheckCompliance() never succeeds. I have tried it on a Surface 2 RT that has lock screen set to 2 mins and a Windows 8.1 Desktop that had a screen saver set to display after 1 minute and show password on resume.
Both of these fail the following check
RequestedPolicy.MaxInactivityTimeLock = TimeSpan.FromSeconds(300);
ComplianceResult = RequestedPolicy.CheckCompliance();
I would expect ComplianceResult.Compliant to be True but it never is. Has anyone ever managed to get this work as expected?
EDIT
Once set i cannot see any way of undoing this on my Surface RT.
I have found a way that the user can do it in this article, Reset EAS Policies However I still cannot see a way of unenforcing in code.
Thanks
As far as I can tell you can only check for compliance of a Policy if one has already been set. If no policy has been set, even if you would be compliant with it, CheckCompliance will return false.
There is no way of Enforcing PIN there is only a way of disabling what Microsoft calls "convenience logons", these are:
Picture password
PIN
Seeing as any user would have needed to already have a user name and password to get the account on the Windows 8.1 device there will always be at least a username\password combo
As title really, I can't see how you can Roll Back an update to a Windows Azure service/site?
Each "update" has a title, so I'd thought you could see a list of these updates, but I just can't see it listed anywhere?
I use https://manage.windowsazure.com, and these are cloud services.
Details on Rollbacks can be found here: http://msdn.microsoft.com/en-gb/library/windowsazure/hh472157.aspx#RollbackofanUpdate
To quote:
Windows Azure provides flexibility in managing services during an update by letting you initiate additional operations on a service, after the initial update request is accepted by the Windows Azure Fabric Controller. A rollback can only be performed when an update (configuration change) or upgrade is in the in progress state on the deployment. An update or upgrade is considered to be in-progress as long as there is at least one instance of the service which has not yet been updated to the new version. To test whether a rollback is allowed, check the value of the RollbackAllowed flag, returned by Get Deployment and Get Hosted Service Properties operations, is set to true.
Note
It only makes sense to call Rollback on an in-place update or upgrade because VIP swap upgrades involve replacing one entire running instance of your service with another. For more information about swapping VIPs, see How to Deploy a Service Upgrade to Production by Swapping VIPs in Windows Azure.
There is no stack maintained of your previous deployments, if however your present deployment somehow fails than the fabric may use your previous deployment(It tries to initialize previous states). Your roles are just VHD(Virtual hard disk) with a copy of OS and your installation files running virtually, whenever you update, a new VHD is allotted and the previous is destroyed(if update was successful). Thus there is no way to get the previous deployments(its destroyed). You should store your previous builds locally or on a foundation server just in case you need it like you now.
I tried to change the role size (upwards) in an Azure role and got the following error after uploading
"The role size specified for role 'Website' in the newly uploaded package differs from the role size for this role in the currently deployed service. Changing the size of the role will cause all local data on the role instance to be lost. Please use the Force flag if you want to allow the loss of local data."
which leads to the question - is there a force flag? Where is it? How do I set it?
Its just appeared!
An update to the Management Portal today (20 Oct 2011) has added an "Allow VM size or role count to be updated" tick box to the Upgrade Deployment dialog. So I guess that's the shiny new Force Flag!
The information I've heard on the Azure forums is that it is not possible to modify the role size without a full redeploy (and this has been my experience as well).
Over time Microsoft has allowed more things to be modified during an upgrade and Mark Russinovich may have suggested in a Mix or TechEd presentation that role size modification would be supported some point in the future.
The error message you are receiving may be an early artefact of the implementation of a size upgrade enhancement. The research I've done (and I have done a LOT of asking around) would indicate that the "Force Flag" mentioned is not actually implemented yet - although I'm more than happy to be proven wrong.
Right now, the vmsize is inside of the package (cspkg) which is sent to AppFabric. It's a decision which is part of the build/packaging. So, to change it, you need to change the VMSize, build the package and then [re]deploy.
If you have a running system, you can avoid down time by using VIP Swap. It will basically stand up another AT[s] in the staging slot with your new VM size and then swap over to it.
So, there's more moving parts involved but you can still change it with virtually no impact.