I'm trying to set desktop backgrounds for our users from Azure Storage using a PS script I'm hoping to deploy.
This script
It just isn't working!
For whatever reason, the script just stops calling at a certain point (line 142 onwards) and I can't work out why.
I've added Write-Hosts at certain points to see where it's getting to and it seems to be that return $Bloblist which doesn't run or go any further.
I can see from the logs that it's showing 'Adding content file from Azure Storage Blob to return list: Background-01.png' etc., but that's it. This tells me that is not a permission error as it is looking where it needs to.
I just can't work out why it's not returning that Bloblist.
If anyone could help that'd be super, as we need to change the desktop backgrounds for every user in the company due to a company name change.
Thanks a lot!
The problem is (probably) not with the script. The problem is likely due to a setup misstep.
You need to debug the code and find out where it's failing to do what you expect.
You could try this or if videos are your thing you could try this.
Related
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
Another team created python scripts within our organization for my team to run. Up until two weeks ago, we all ran them without any problems. Then one day, some users have been unable to run them successfully on the same machine.
All users are admins with LUA disabled. All users should have the same permissions.
The complicating factor here is the team created a "framework" which generates code from a combination of the framework, and an excel file for the tests being run. This prevents me from stepping through the code and finding where it's specifically failing. Beyond that, the same exact script runs on the same machine when another user trying to run it.
Specifically, in the script, it appears that when the affected users are running the script, IEDriverserver doesn't appear to open. No errors are given.
Is there any environmental variables that could be specific to users that would cause this? Even a direction to look would be extremely helpful.
Does it always fail in the same part of the Python code? Does opening the Excel file have anything to do with it, perhaps? I mean, if someone has the Excel file open on a network drive, and someone else is trying to write to the file, i'm pretty sure this will trigger an error, unless the Excel file is 'shared'. Just a couple thoughts.
I encountered the similar issue today. I happen to solve it by unset PYTHONHOME and PYTHONPATH. Not sure if this helps.
I have recently deployed a fubu mvc application to windows azure. Everything works except when the pipeline tries to find the view to render. This all works correctly on my local machine.
So I am wondering: does the process on the Azure box have rights to read/scan files on disk?
Any suggestions to fix it are welcome though.
EDIT:
As part of the deployment there is a stage that azure goes through called "Preparing files for eployment". I checked on the log and my view was not in there
So I changed copy to output as true and it worked
It depends a bit on where you are trying to read and how you have configured your roles. By default, the code will run as a very low privilege user that only has R/W to the code directory (and any LocalResource(s) defined by the user). However, you can run your code as SYSTEM, in which case you can R/W anywhere (you might still have to take ownership, but you are all powerful as SYSTEM).
If your views are defined as part of your package and uploaded, the code should have permission to view it. I am curious as why you think this is a permission issue right now. Do you see an error that indicates that, or are you guessing it? If I had to guess, my first thought would be your views didn't get packaged correctly and are not on the VM. You can confirm they are there either by RDP or by cracking open the package and snooping around.
I am trying to attach a cloud drive as described here http://msdn.microsoft.com/en-us/library/gg466226.aspx#bk_Storage but I get the error ERROR_AZURE_DRIVE_DEV_PATH_NOT_SET ?
What does this mean? I've tripled checked my config at it seems ok.
I am trying to connect the cloud drive in a Windows Service on a VM Role.
I discovered that the FixMSI.js script from http://msdn.microsoft.com/en-us/library/gg466226.aspx#bk_Install was failing. For some reason $(BuiltOutputPath) was empty. I did it relative to the $(ProjectDir) instead.
It then failed with a different error (and much earlier). CloudDriveException 0x80070103.
Searching for this gave me this article which basically told me to manually edit the driver inf file for the wa miniport. http://msdn.microsoft.com/en-us/library/windowsazure/hh708321.aspx.
Now it attaches ok. The strange thing now is that the device has a warning when the vm starts (but only when hosted in azure), I have to manually go into the vm on azure and update the driver.
try to change BuiltOutputPath to BuildOutputPath. According to Richard, this is an error in the document. Refer to the Community Content section on the document for more information.
I've run into a little problem here. What I get on my local environment and my cloud result is different... I've tried using IntelliTrace, but everytime I want to debug a track it gives me a No source available message.
There aren't any exceptions or anything like that, everything loads perfectly fine... it just seems like the 4th case of the switch-case is screwed. I'm using 4 const ints in a static Common.cs file to populate these 4 possibilities; I know I could be using an enum, but it shouldn't really matter, right?
If this helps, I am also using Telerik's RadChart control. In other words, these 4 options manipulate the data in 4 different ways. People have told me that there is no way to debug code hosted within Azure, and that I could probably use Azure Diagnostics and keep tracing every few lines or so...
Does anyone have any pointers on which direction I should go? or have faced similar problems before? Many thanks... I am pretty much clueless in here.
EDIT: The problem lay with the localization on Azure. On my local machine the date format is dd/mm/yyyy, whereas on Azure it is mm/dd/yyyy. Hence, the problem arose...
It seems to me you're using a web role. If that's the case, the quickest way to explore differences between local deployment and azure deployment is to enable Web Deploy on your cloud project.
Once you've done that, use the Publish option on the Web project (NOT on the cloud project) to quickly upload your code changes to Azure, and explore doing old-fashioned Response.Write.
Ugly, but quite efficient when you don't get what's happening.
Pierre