When I'm using ios 11, since it's security permissions have been changed for allowing an app to access users' location, how can we do monitoring(enter/exit) when user only gave us "access only when using the app"? is there any way at all that we can do monitoring without that permissions?
If you only have "when in use" location permission, monitoring is not useful in practice. There is simply no way to get callbacks when your app is not in the foreground.
When your app is running you may call locationManager.requestState(for: region) (See here) to see how the region inside/outside status has changed since your app was last running. This is really the best you can do.
Related
I am trying to set up a web application to work in IIS.
Among other things, I have created an "application" node pointing to my directory with binaries.
That application node uses pass-through-authentication, and it uses an AppPool for which my current user is set as the identity.
For some reason, IIS thinks it cannot access those files, as evidenced by the "Test Connection" output:
The user name + password combination is definitely correct, as IIS checks the validity of the credentials already upon input.
Note that this is by far not the first time this is happening: I have set up this web application on many, many machines already over the past five years, and yet, every single time a new developer joins the team, or we have to set up a new machine, we keep struggling with these access rights issues for multiple hours, or even days.
In the end (just like I have started in this case), all kinds of users (<machine name>\User, <machine name>\Benutzer, "Everyone", authenticated users, administrators, anonymous user, IIS_IUSRS, ...) have been granted full access to all files on the disk. Usually, at some point (after so much trying, configuring, switching forth and back, that no-one knows what actually solved the issue), the problem is gone.
What is a more systematic and minimal approach to troubleshooting (or, better yet, avoid) this issue when setting up a web application in IIS?
For file access issues, use Process Monitor will be fine.
Set the filter as "Process Name is w3wp.exe" "Result is not SUCCESS"
Add "user" column. Then you can check at which step, user access files unsuccessfully.
I am having architecture where my BOT server is on Cloud VM. To access that VM, I do RDP. I scheduled all the BP jobs on that BOT on VM. Now when I am connected to VM using RDP and keep the Blue Prism window in foreground, my BP jobs are running fine, means in Attended mode, they are fine. But if I minimize that BP window or if I dont do RDP to VM machine, I am getting error 'failed to navigate'. That means in unattended mode on my Cloud based VM BOT server, jobs are not running.
NOTE: My BP VM machine is always up and running also its not getting locked also, as I disabled windows screen lock (alt+ctrl+del).
In this scenario, will logon agent help or any other suggestions?
Utilizing an environment relying on RDP is not supported or recommended by Blue Prism, as it causes issues with automated processes (as you describe). Please refer to page 4 of the Blue Prism Data Sheet - Remote Access Tools (available in the Documents tab of the Blue Prism client portal):
The following tools have been deemed to be specifically unsuitable for providing remote access to Blue Prism environments:
Remote Desktop Connection (RDP)
The way that this Windows tool (and other tools that use the RDP protocol) handle session management is not compatible with Blue Prism:
The underlying operating system is aware as a connection is
established which can, subject to the automation techniques being
applied, result in the executing automation being interupted.
It requires the remote access credentials to be aligned with the
credentials used to authenticate the target system against the
network which presents a potential security risk.
As a user authenticates any previously connected users are locked out.
Each connection creates a separate desktop session.
The connection is not maintained throughout a system reboot.
It does not matter whether the VM is in cloud or within your own infrastructure, they both have same issue. Blueprism needs "screen" to be able to interact with applications. VM of course does not have a physical screen, but there is still a virtual one (I don't mean the RDP one by this) as the virtualization layer provides virtual GPU and monitor.
Imagine a non-virtual pc left unlocked. This is the same. Even if you don't see it (you have to look for "console", some clouds provide access to it), it exists.
There are more possibilities how to solve it, two of them are:
1) use Blueprism Login Agent
This will unlock the physical/virtual screen of the machine with given AD/Windows credentials, like a human user would before he starts working with the pc.
Please search internet for more infor about it or look up videos on youtube, like this one: https://www.youtube.com/watch?v=Eeeeu_iHjzk&list=PL4SEtvjUqihFh-iFvb_s0VAhPCX1tzg2A&index=43
(I am not the author of this video nor affiliated with the author)
2) modify Windows registry setting to log in automatically
More info: https://support.microsoft.com/en-us/help/324737/how-to-turn-on-automatic-logon-in-windows
I've encountered this problem before.
Try using the BluePrism's "Login Agent"'s "Login" process with the BOT's credentials.
If you continue to get this error, try using a "Dynamic" Spy mode for a particular attribute.
Good luck.
In the Azure Management Portal, you can configure your website. As an example, you can change the PHP version your website is using. When you have edited a configuration option, you have to click “Save”.
So far, so good. But you also have the option to restart your site (by clicking “Restart“ next to “Save”).
My question is, when should you restart your website? Are there some configuration changes that require a restart, and others that don't? I haven't found any hints in the user interface.
Are there other situations that require a restart? Say, the website has been running for a given time without a restart?
Also, what are the consequences of restarting a website? Does it affect cookies/sessions in any way (i.e. delete a user's shopping cart or log them out)? Are there any other consequences I should be aware of?
Generally speaking, you may want to restart your website because of application performance issues. For example, you may have a memory leak in your application, connections not getting closed, or other things that would degrade the performance of the application over time. As you monitor your website and observe conditions like this you may make a decision to restart it. Even better, you may even automate the task of restarting when these conditions occurr. Anyway, these kinds of things are not unique to Azure Websites. You would take similar actions for a website running on-premises.
As for configuration changes, if you make a change to your web.config file, this change is detected and your website would be restarted automatically for you. Similarily, if you were to make configuration changes in the CONFIG page of your website in the Azure Management Portal such as application settings, connection strings, etc., then Azure Websites will detect this change to your environment and automatically restart it.
Indeed, restarting a website will result in any session data kept in memory being lost for that instance. Additionally, if you have startup/initialization code that takes time to complete then that will have to be rerun. Again, this is not anything unique to Azure Websites though.
Whenever we get the error "Role Instances are taking longer than expected". The only possible options to do are .
Shutdown the emulators and try again.
Restart the machine and see if that helps.
Uninstall the Azure Tools for that version.
Some times uninstalling the same takes a long time,some times even days. It appears that some process or service is blocking the same. Has anyone faced this before ? If yes does anyone know which process would be blocking the same?
When an instance starts it will run the OnStart method on the worker/web role (depending on your service type). The more stuff you have in there, the more time it will take to start up the role. Common caveats are the Cache as mentioned and blob/table storage (if you do read/write/create when you start the role).
Try minimizing the OnStart's workload and moving any storage stuff in async tasks.
I have had similar problems as well in the past
IISConfigurator could not map the web roles in IIS. In my case it was due to corrupted file system ACLs on the code directory. See logs under C:\Users\YOUR_USER_NAME\AppData\Local\dftmp\IISConfiguratorLogs\
Another cause might be that something else has tied up the Port Numbers that Azure is trying to bind your web role on. Or that the ports that the local storage needs for tables/blobs and queues (10000-10002) have been taken by another app. Open a command prompt and run netstat -anb
Try running the Visual Studio using "Run as Administrator" option.
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.