This question already has answers here:
Windows Azure Storage Certificate Expired
(4 answers)
Closed 9 years ago.
I'm having trouble with a number of role instances refusing to leave the "waiting for status" state. It's the same problem that a user had here.
My Azure subscription comes from BizSpark and therefore I don't have the ability to submit a support ticket to get this problem fixed (assuming it is the same problem of a bad node).
Presumably, although my subscription comes from BizSpark, I'm still entitled to a functional service. Could anybody help me come up with a self remedy or a way of contacting support please?
Thanks!
Several Azure services are having problems at the moment, check here first:
http://www.windowsazure.com/en-us/support/service-dashboard/
I don't think that having a Bizspark-based subscription excludes you from buying support. The support plans should have something that fits your needs. The cheapest plan that will allow you to submit a support ticket (via the web) is $29 per month. I suggest that Bizspark or not, that you spring for at least the $29, so that you can get attention to your issues.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Joined a company using skype for business. Surprised to find there is no folder hierarchy, import/export contact list. (maybe business is so easy to be ripped off these days). Haven't found an existing tool to interact with skype client to export/import contact. Some tool (http://support.express-desk.com/support/Skype-for-Business-Online-Contact-Manager) need office365 admin permission which I don't have.
Is there open source (ex: lib skpy or #github) to share global team skype hierarchy among teammates?
At first you need to understand that Skype for Business online (hosted by Microsoft in the cloud) isn´t the same as Skype for Business on Premises (selfhosted inside your organization). Most features are identically however some are a little bit different (mostly not seen by the user).
So both solutions use a centralized share to host contacts which only an Administrator can manage. On an on premises environment an Skype for Business Administrator might add an contact to the global Adressbook. However this often results in a kind of garbage as more and more such contacts where created here and they where never cleaned up. So most companies to not perform that and relay on the users to keep there own contacts locally.
The link you mentioned is by the way nothing else as an 3rd party GUI for the so called "Unified Contact Store" (more infos here).
The normal way by the way to import / export contacts is via Outlook. The MS Exchange server is normally connected to the Skype for Business environment and therefore will sync the contacts (if configured correctly as explained here or here). So in theory you could export your contacts and send that over to your team. They all can import them and you can then see those in Skype for Business.
P.S. Please keep noted that the contact list is limited to something around 200 entries (see here). And allows an Administrator to manage that via GUI. However a 3rd party software isn´t really something which is supported by Microsoft, so most companies might not have a look into that to avoid to break something.
I just started developing an Intuit App yesterday and was really getting going on integrating with QuickBooks Desktop. Then today I logged in to continue work and was greeted by several missing pages on Intuit's IPP site and a link that says "Deprecated QBO V2 and QBD V2,V3". The only API that appears to not be deprecated is QBO V3.
I cannot find any announcement from Intuit about any upcoming deprecation. Does anybody have any info on whether I am safe to continue developing my app to connect to QBD or do I need to talk to our accountant to move over to QBO instead?
EDIT: I have marked Jarred's answer as the accepted answer because he associated with Intuit and answers my specific situation. Also check Charlie's answer for additional details specific to other scenarios.
I interviewed several people from Intuit at the Sleeter Accounting Solutions Conference this week, including (amongst others) Dan Wernikoff, Senior VP.
I'll have an article in my blog on this (http://www.sleeter.com/blog/) next week - I'm transcribing my recordings and clarifying points.
There are a LOT of points here, but to address what you are looking at -
If you are writing an IPP app using V3 for QBO - no problem (and in fact, some good news there).
If you are already published with IPP using V3 and Sync Manager for the Desktop, you will get continued support but don't expect any advancement there (unless you are someone big like American Express).
If you are NOT already published with IPP for the Desktop - the SDK is your option.
And there is a lot more info about this coming out
MINOR EDIT AT A LATER DATE: If you have been working with IPP for the desktop you MIGHT get approved to continue - no guarantees on that (but it seems they might be lenient). But In my opinion you can't expect any significant new features (as in, more data access) moving forward unless you are a significant partner with a contract with them (such as, American Express).
Intuit will not prevent you from going live with your application that you have spent the last 6 months working on. We have a set of guidelines for grandfathering in developers who have invested in using the v2 REST API for QuickBooks Desktop.
feel free to contact me directly if you have more questions.
#Charlie if you could correct your statement regarding if you are NOT published then you need to use the QBXML SDK. That is too generic, we will evaluate each developer on a case by case basis.
regards,
Jarred
My writeup on this subject is available at http://www.sleeter.com/blog/2013/11/quickbooks-software-integration/
Note that Dan Wernikoff, Senior VP at Intuit, has been leaving comments in several of my articles in the blog.
Blair, you have a reasonable concern. However, given the REASONS that they made this change, I would SPECULATE that Intuit won't be pulling the SDK. What isn't clear, at this time, is HOW MUCH support they will give the SDK moving forward.
And, as we have seen for several years now, things can change...
I'm having a rather general question, in the sense that I'm not even sure that it's possible. I'm trying to gather some opinions about it, coming from more experienced people.
Imagine, that I'm a member of three (just to say a number) online book stores. Over the years I have bought quite some books on all three accounts. Now, let's say I want to create an application that can login to these three accounts and do server requests to sort all my books in a single list. So that I can access my books from a single location, similar to what Pidgin or Trillian does with multiple instant messenger services.
Is that even a realistic option? Of course I dont know which server requests I would have to do and/or in which data format the data will be sent back. Assuming that this doesn't infringe every EULA out there, how would you approach this?
It's all a bit vague, but that's all I have at the moment :)
thanks a lot in advance.
I'm afraid you'll have to talk to each server via its own API (assuming it has one). You can then get the relevant info from each server and process it in your app (e.g. get the common info, aggregate it in a single list, sort...).
This is more or less what pidgin/trillian do.
IMHO the more interesting problem occurs when you want to buy a new book via your app :)
I have been asked to set up a demo site which calls out to WorldPay to authorise transactions.
We won't have a MerchantID or anything like that yet, is there a dummy service that you can call that is either on the internet at-large, or is downloadable and you can install locally?
I've obviously had a look around and so far come up with nothing - it's a straightforward answer so wondering if anyone on here knows off the top of their head?
Thanks
Was a few years ago but as far as I remember:
If you (or your client) are going to be signing up with Worldpay then they provide both live and test accounts.
I seem to remember that you have to put a successful transaction through the test account before they will activate the live one for you.
Thier support dept used to be very helpful so I'd suggest just giving them a ring
It's in their interests to get you up and running so they can start charging you for it
I have a little experience with bug tracking systems such as FogBugz where help tickets are issues are (or can be) bugs, and I have some experience using a bug tracking system internally completely separate from a help center system.
My question is, in a company with an existing (home-grown) help center system where replacing it is not an option, how should a bug tracking system (probably Mantis) be integrated into the process?
Right now help tickets get put in for issues, questions, etc and they get assigned to the appropriate person (PC Tech, Help Desk staff, or if it's an application issue they can't solve in the help desk it gets assigned to a developer). A user can put a request for small modifications or fixes to an application in a help ticket and the developer it gets assigned to will make the change at some point, apply their time to that ticket, and then close the ticket when it goes to production.
We don't currently have a bug tracking system, so I'm looking into the best way to integrate one. Should we just take the help tickets and put it into the bug tracking system if it's a bug (or issue or feature request) and then close the ticket if it's not an emergency fix? We probably don't want to expose the bug tracking system to anyone else as they wouldn't know what to put in the help center system and what to put in the bug tracker... right?
Any thoughts? Suggestions? Tips? Advice? To-dos? Not to-dos? etc...
Have a promote to bug button on the help desk system, that publish the ticket on the bug tracker, with the appropiate reference info.
Is this for a production system with end users reporting bugs, or for issue resolution during QA?
If it is the former, some live person should triage the help desk tickets and only log as a bug what really is one.
If it is the latter, you should not integrate at all.
Well, it's a tradeoff.
We use separate systems for help desk tickets and for bugs.
Pros:
Workflows & requirements will probably different between devs and help desk, you can choose a system for each that fits requirements (e.g. fields that are only relevant for dev or for help desk, different kinds of email integration).
Clear responsibilities: Help desk handles tickets, devs handle Bugs.
Cons:
Integration will not be quite seamless (you need either automatic integration, which does not always exist, or manual back-forth links, which people may forget).
So far, we're quite happy with two products. It is occasionally annoying to have to paste links or close a ticket and a bug, but usually tickets and bugs are handled by different people anyway, so it's not a big deal.
One product might also work well, if you can find one which fits everyone's workflow.
In the raiseaticket help-desk system, we create a separate workflow for Prod, Dev and Bugs. The ticket is assigned to relevant group based on the nature of the issue. These tickets are not exposed to any other group. So, we can do a workaround in our help-desk portal system for the bug tracking.
For anyone in 2022 (and beyond) looking to integrate a help desk system and bug tracker, DoneDone does this well.
We use a DoneDone mailbox for general customer support (both via our support email address and the contact form on our website). It lets you have private discussion on emails, along with allowing you to assign, prioritize, tag, and create/change statuses on them (e.g. "Open", "In Progress", etc.)
We use DoneDone projects to manage internal bugs/issues/tasks.
DoneDone lets you connect support emails (the helpdesk part) to internal tasks (the bug tracking part) as well. So, if your company has distinct support and client-facing people while also having internal devs and you want to separate their work, you can create any number of subtasks from an incoming conversation.
Even if your company isn't that stratified, it's nice to be able to create bugs with their own workflows separate from a helpdesk ticket (which has its own workflow).
More info at https://www.donedone.com