I've been following instructions on the Azure site to add a CNAME to point to my Azure website. I have had some problems getting it to work and there seems to be some contradictory information in some of the posts.
I have my website running in "Shared" mode, which according to the Azure instructions supports custom domains and indeed it seems to allow me to manage domains. But some posts seem to indicate that I have to run in reserved mode. Can anyone confirm this?
Also, some posts seem to indicate that I need to add the CNAME in the Azure management portal, but I cannot find where this is. Any help appreciated?
I don't really understand A records and CNAME that well. My DNS provider allows me to add both. Do I need to change both? Currently my A record points the "root" to the IP address that Azure gives me and the CNAME points www.mydomain to the Azure website host mysite.azurewebsites.net. I have left them for a while to propogate and nothing seem to happen.
The notion of FREE, SHARED, RESERVED website categories are very recent; Microsoft Launched it just 2 days ago. Earlier it used to be either FREE or RESERVED. You get to attach a custom domain name only for reserved instance.
With the new feature of low cost shared option, you get to attach a custom domain but it will still be in the shared pool of Azure Websites. It works out around $9.36 a month.
The reason for contradiction info in the posts are due to new to features. In short you can use both SHARED and RESERVED for attaching custom domain. With shared it is little cheaper provided you are fine with your website being served for shared pool.
Just go the SCALE Table and make your website instance SHARED from default free and then go to Configure table to put your CNAME
DNS Management is handled differently by different domain or hosting providers , there are three places these changes can be performed (may be more )
cpanel
domain manage panel
WHM panel
if you have only taken a domain most probably your domain provider will send you a url, in which "manage dns " option will be there.
if your site is already hosted then you might have to do it in cpanel or whm.
so better call your domain hosting provider for exact steps . it saves a lot of time
Related
I have not found clear documentation about this.
My company would like to migrate/move domain A in Google Workspace A to domain B in Google Workspace B.
We are also using Google cloud in both workspaces.
Since each Google workspace has a domain (A and B respectively) as a primary domain, we cannot remove domain A from its respective Google workspace, which is required for adding it as a secondary domain to Google workspace in domain B.
Merging 2 domains is possible, but it entails cancelling Google workspace/cloud identity on source domain A, if I understand correctly link.
It also involves saving Google workspace data, which takes days and needs to be tested.
There is also the question of whether users can still access Google resources such as cloud, while this transition is happening.
It is necessary to remove domain A from its workspace, before adding it to workspace of domain B. This means downtime, and I am unsure if Google cloud resources in domain A's workspace will be lost in transition.
Perhaps someone could shed light on the process.
I have researched documentation on Google about the migration.
There is a FAQ about multiple domains.
My Teams app:
multi-tenant
deployed using Teams Toolkit to Azure Storage, CDN enabled with a Custom Domain
in alpha use by internationally distributed organisation (third party, not me), users around the world
the app functionality works fine including multi-tenant
in rapid development so frequent code updates. Very rare manifest updates.
Problem:
I frequently update the app's code and deploy the update to Azure using Teams Toolkit
when I do this users often report 'blank tabs' for a period of time, can be many hours. They see the tab menu but the tab contents are simply blank. Purging the CDN doesn't seem to help.
seems most common using Teams desktop app but also reported using browser and mobile Teams app
I think this may be an issue of code deployment .js files (each of which gets a new filename) not being available to the install, I can sometimes reproduce but very unreliably. Other times I can access the app, using a user account on the client's AAD, successfully from different locations (using a VPN to emulate location).
Previously the app's Custom Domain was managed on Cloudflare's proxy.
I disabled this and implemented Azure CDN.
Users continue to report the problem.
This is very poor user experience.
Does anyone have experience of this or hypotheses on what may be happening?
Thanks.
Would suggest to test one thing first: manually deploy a new code change to Azure storage, with the same storage-CDN-custom domain setup.
See if this also causes the hours delay symptom.
By doing this, if the issue is reproducible, it may indicate that the Azure Storage-CDN configuration needs to be optimized.
Otherwise please share the result and it will help narrow down the root causes.
I want to set up an intranet that can be accessed in more than one location.
I want the server to be located in one location and be accessed in another. For example it would be at the users home, or in one of our many offices. At the moment I can't see more than 7 people using it, so we won't need anything large to start off with.
I use Wampserver for building our webpages, but I don't think Wampserver will be enough to do what we need. As if I set up Wampserver it is only accessible from the building we are in. I do not want to open the firewall to put it online as the pages that we will be serving will not be for the public.
The typical way of doing this is to set up and configure a VPN solution for your home users. You could do this yourself or use a third party solution. Normally, you would allow VPN users access to specific resources, such as your intranet server.
The other alternative is to allow public access to the intranet server, but implement authentication on the intranet server so only your users can access the content.
I would normally go for the former as a more secure solution, but it depends on your environment and requirements.
Iam building a web portal which will be rented to customers on a hosted model (SAAS), where they will be using the entire portal features on their own domains with their own branding.
Now I don't want them to get the files of my web-portal, but still be able to use a custom branded portal.
One solution which someone suggested here was to host the branded version on my server and all it via an Iframe on the customer's domain. However I didn't like the idea very much.
One second approach which I researched and found was to host the portal on a fresh IP in my server and ask the customer to point his domain to that ip.
The webportal will be sold to lot of customers and they all will have separate User Interfaces and brandings, so this is needed.
Please suggest me what do you feel about my approach or if you guys have a better idea in mind please pour in your suggestions.
iFrames are evil.
With that said I would probably go with a subdomain approach. They add a subdomain like webportal.somecompany.com that points to you and have your webserver route them to the correct hosted instance of your application based on subdomain. That way their www.somecompany.com still goes to their website.
We're running a SAAS application that supports branding, and we do it by dynamically serving up CSS. If all of your customers have a unique domain name pointed at your server, you could select your CSS files by domain name: If a customer logs in at "http://portal.customer.com/login", you can have his HTML link to the file "/stylesheets/portal.customer.com.css", and so forth. Alternatively, you can create a subdomain for each of your customers, and point them all at your master server, using very similar code to pick the CSS.
This lets you have a single IP address for all customers (and only as many servers as you need to support all your customers behind that IP address), instead of one IP address / server per customer - should cut save on hosting costs!
(NOTE: I'm leaning toward the subdomain approach, the more I think about it. If you're using HTTPS, it would let you use a single "*.yourdomain.com" certificate, rather than trying to mess with separate certificates for each client domain.)
You don't need to run different IPs for different customers. HTTP 1.1 supports Host: like so
GET / HTTP/1.1
Host: example.com
This is how most shared hosts work. When a customer sets up their DNS records to point at your server/load balancer, the incoming requests will have your client's hostname in the headers. Whether you set up virtual hosts in say Apache or do it at the application level is up to you.
Please for your own sake don't do iframes. There's a lot of information on the web on architecture for multi tenant applications.
I made the experience that in such a scenario your customers will come up with any possible web UI requirement you can imagine. Therefore it is rather difficult to build a web UI framework that can accomodate to all the needs, in fact this would rather be a content management system.
Furthemore, for building the web UI, you may meet any combination of customer in-house development, 3rd party web agency or request to get it developed by yourself.
In such situations I made good experiences with offering the SaaS as actual web services allowing custom developed portals to run on top. With this, anybody can build the actual portal with the clients look and feel. You could offer development and hosting as an option.
I'm working for the first time on a MS Dynamics CRM 4.0 project. Our company has a high number of remote employees and even more remote consultants. As such it will be necessary to make the CRM solution available over the internet. As near as I can tell, I have three options:
Have everyone use a VPN to access an intranet site (typical onsite deployment). However, we have found that VPNs are far from trouble free and cause many support issues. We avoid them like the plague.
Use IFD to expose the CRM on the internet. I don't know much about this except that the URL will be different than the onsite URL, which could cause some headaches (see below).
Expose the CRM site by opening the site to the internet, using SSL to encrypt traffic. We currently do this with our MS sharepoint sites. I'm not sure how secure this would be (one of the reasons for this question).
I'd like to avoid using both the onsite intranet deployment and the IFD together for a couple of reasons. One of the requests for the solution is use email to notify users that they've been assigned a task, and include the URL to the task within the email. For this reason. If both deployments are used, then I'll need to include two URLs and the user would need to know which to use. Which leads to the second reason, the main users of the solution split time between being in the office and being remote. Thus they would need to access the solution two different ways, and know when to use which. Bad.
So, what are the advantages/disadvantages of any of these methods? Any other options? Is there any issue using IFD from within the intranet? Security issues?
UPDATE:
Be sure to read the comments of the accepted answer, as they further explore the ramifications of the various options.
That is the best, you have all the security, and a low maintenance deployment. Also if you are developing custom code (ASPx pages) you will have only one deployment type to support. If your users are already using a VPN Client, this should be the best solution.
This is the Microsoft way to do it. Except for the URL duplication. This solution is used in companies where clients do not want to have a VPN client, or where VPN clients can't pass thru firewalls. Also this solution is almost required if your outlook clients are using "Connect to exchange thru the web". Because in this case all the clients can open Outlook without VPN, CRM should be exposed without VPN, and the IFD deployment is handled natively by the Outlook client. Note that this is SSL enabled (required). EDIT : It's not required, but a best practice, even if the implementation guide says "You must define a URL for the Microsoft Dynamics CRM IFD by using the following format: https://".
This this the worst of all the worlds, you have to maintain the deployment manually, and you will have all the headache of using a deployment as we were using it in CRM 3.0 (NTLM, Kerberos etc). I do not recommend this.
You can use an IFD deployment thru the intranet, but there is some buggy behavior. The external DSN should be configured on the internal DNS server, so that internal client can access the internal server. And because IFD is SSL enabled, you are encrypting internal traffic...
Hope this help!