STW Services

Category: Micrososft

  • Configure alternate access for mappings in SharePoint 2013 : Part 1

    Post Views: 2,088

    Configure Alternate Access For Mappings – In this article you will learn how to configure alternate access mappings in SharePoint 2013. Each of  web application can be associate with a collection of mappings between internal and public URLs. Both  the URLs internal and public consist of the protocol and domain portions of the full URL.

    A public URL is what users can access the SharePoint site, and that URL is what appears in the links on the pages. Internal URLs is in the URL requests that sent to the SharePoint site. Many internal URLs can be associated with a single public URL it means we can use many internal URL’s for single public URL.

    Each web application supports five collections of mappings per URL. The five collections correspond to five zones (default, intranet, extranet, Internet, and custom). When the web application receives a request for an internal URL in a particular zone, links on the pages returned to the user have the public URL for that zone.

    How To Manage alternate access mappings

    1. On the SharePoint Central Administration website, click on System Settings And then.
    2. On System Settings page, in the Farm Management section, click  on Configure alternate access mappings.

    Adding an internal URL for mapping

    1. On the Alternate Access Mappings page, click to  Add Internal URLs.
    2. In the mapping collection you want to change is not specified, then choose one. In the Alternate Access Mapping Collection section, on the Alternate Access Mapping Collection menu, click on Change alternate access mapping collection.
    3. On the Select an Alternate Access Mapping Collection page, click a mapping collection.
    4. In the Add internal URL section, in the URL protocol, host and port box, type the new internal URL (www.example.com)
    5. In the Zone list, click the zone for the internal URL.
    6. Click Save.

    Edit and delete internal URL for mapping

    1. On the Alternate Access Mappings page, click the internal URL that you want to edit or delete.
    2. In the Edit internal URL section, change the URL in the URL protocol, host and port box.
    3. In the Zone list, click the zone for the internal URL.
    4. Do one of the following:
      • Click Save to save your changes.
      • Click Cancel to discard your changes and return to the Alternate Access Mappings page.
    5. Click Delete to delete the internal URL.

    Edit public URLs for mapping

    1. On the Alternate Access Mappings page, click Edit Public URLs.
    2. If the mapping collection that you want to change is not specified, then choose one. In the Alternate Access Mapping Collection section, on the Alternate Access Mapping Collection menu, click Change alternate access mapping collection.
    3. On the Select an Alternate Access Mapping Collection page, click a mapping collection.
    4. In the Public URLs section, you can add new URLs or edit existing URLs in any of the following text boxes:
      • Default
      • Intranet
      • Extranet
      • Internet
      • Custom
    5. Click Save.

    Map an external resource url

    You can also define mappings for resources outside intranet applications. You must supply a unique name for URL, The initial URL, and a zone for that URL. The URL you request must be unique to the farm.

    1. On the Alternate Access Mappings page, click to Map to External Resource.
    2. Next click on Create External Resource Mapping page, in the Resource Name box, type a unique name.
    3. In the URL protocol, host and port box, type the initial URL.(www.example.com)
    4. Click Save.

  • Kentico Deployment on Azure

    Post Views: 1,139

    Kentico Deployment on Azure – 1 Deployment

    1.1 Kentico Deployment on Azure

    1.1.1 Azure Support

    On the Scale page of the Azure Management Portal, you can manually scale your application or you can set parameters to automatically scale it.

    A. Manually scale an application running Web Roles or Worker Roles

    On the Scale page, you can manually increase or decrease the number of running instances in a cloud service.

    1. In the Management Portal, click Cloud Services, and then click the name of the cloud service to open the dashboard.

    2. Click Scale. Automatic scaling is disabled by default for all roles, which means that you can manually change the number of instances that are used by your application.

    1

    3. Each role in the cloud service has a slider for changing the number of instances to use. To add a role instance, drag the bar right. To remove an instance, drag the bar left.

    2

    You can only increase the number of instances that are used if the appropriate number of cores are available to support the instances. The colors of the slider represent the used and available cores in your subscription:

    o Blue represents the cores that are used by the selected role
    o Dark grey represents the cores that are used by all roles and Virtual Machines in the subscription
    o Light grey represents the cores that are available to use for scaling
    o Pink represents a change made that has not been saved

    4. Click Save. Role instances will be added or removed based on your selections.

    B. Automatically scale an application running Web Roles, Worker Roles, or Virtual Machines

    On the Scale page, you can configure your cloud service to automatically increase or decrease the number of instances or Virtual Machines that are used by your application. You can configure scaling based on the following parameters:

    • Average CPU usage – If the average percentage of CPU usage goes above or below specified thresholds, role instances are created or deleted, or Virtual Machines are are turned on or turned off from an availability set.
    • Queue messages – If the number of messages in a queue goes above or below a specified threshold, role instances are created or deleted, or Virtual Machines are are turned on or turned off from an availability set.

    C. Average CPU usage

    1. In the Management Portal, click Cloud Services, and then click the name of the cloud service to open the dashboard.
    2. Click Scale.
    3. Scroll to the section for the role or availability set, and then click CPU. This enables automatic scaling of your application based on the average percentage of CPU resources that it uses.

    3

    4. Each role or availability set has a slider for changing the number of instances that can be used. To set the maximum number of instances that can be used, drag the bar on the right to the right. To set the minimum number of instances that can be used, drag the bar on the left to the left.

    Note: On the Scale page, Instance represents either a role instance or an instance of a Virtual Machine.

    4

    The maximum number of instances is limited by the cores that are available in the subscription. The colors of the slider represent the used and available cores in your subscription:

    o Blue represents the maximum number of cores that the role can use.
    o Dark grey represents the cores that are used by all roles and Virtual Machines in the subscription. When this value overlaps the cores used by the role, the color turns to dark blue.
    o Light grey represents the cores that are available to use for scaling.
    o Pink represents a change has been made that has not been saved.

    5. A slider is used for specifying the range of average percentage of CPU usage. When the average percentage of CPU usage goes above the maximum setting, more role instances are created or Virtual Machines are turned on. When the average percentage of CPU usage goes below the minimum setting, role instances are deleted or Virtual Machines are turned off. To set the maximum average CPU percentage, drag the bar on the right to the right. To set the minimum average CPU percentage, drag the bar on the left to the left.

    5

    6. You can specify the number of instances to add or turn on each time your application is scaled up. To increase the number of instances that are created or turned on when your application is scaled up, drag the bar right. To decrease the number, drag the bar left.

    6

    7. Set the number of minutes to wait between the last scaling action and the next scale-up action. The last scaling action can be either scale-up or scale-down.

    7

    All instances are included when calculating the average percentage of CPU usage and the average is based on use over the previous hour. Depending on the number of instances that your application is using, it can take longer than the specified wait time for the scale action to occur if the wait time is set very low. The minimum time between scaling actions is five minutes. Scaling actions cannot occur if any of the instances are in a transitioning state.

    8. You can also specify the number of instances to delete or turn off when your application is scaled down. To increase the number of instances that are deleted or turned off when your application is scaled down, drag the bar right. To decrease the number, drag the bar left.

    8

    If your application can have sudden increases in CPU usage, you must make sure that you have a sufficient minimum number of instances to handle them.

    9. Set the number of minutes to wait between the last scaling action and the next scale-down action. The last scaling action can be either scale-up or scale-down.

    9

    10. Click Save. The scaling action can take up to five minutes to finish.

    D. Queue messages

    1. In the Management Portal, click Cloud Services, and then click the name of the cloud service to open the dashboard.
    2. Click Scale.
    3. Scroll to the section for the role or availability set, and then click Queue. This enables automatic scaling of your application based on a target number of queue messages.

    10

    4. Each role or availability set in the cloud service has a slider for changing the number of instances that can be used. To set the maximum number of instances that can be used, drag the bar on the right to the right. To set the minimum number of instances that can be used, drag the bar on the left to the left.

    11

    Note: On the Scale page, Instance represents either a role instance or an instance of a Virtual Machine.

    The maximum number of instances is limited by the cores that are available in the subscription. The colors of the slider represent the used and available cores in your subscription:

    o Blue represents the maximum number of cores that the role can use.
    o Dark grey represents the cores that are used by all roles and Virtual Machines in the subscription. When this value overlaps the cores used by the role, the color turns to dark blue.
    o Light grey represents the cores that are available to use for scaling.
    o Pink represents a change has been made that has not been saved.

    5. Select the storage account that is associated with the queue that you want to use.

    12

    6. Select the queue.

    13

    7. Specify the number of messages that you expect each instance to support. Instances will scale based on the total number of messages divided by the target number of messages per machine.

    14

    8. You can specify the number of instances to add or turn on each time your application is scaled up. To increase the number of instances that are added or turned on when your application is scaled up, drag the bar right. To decrease the number, drag the bar left.

    15

    9. Set the number of minutes to wait between the last scaling action and the next scale-up action. The last scaling action can be either scale-up or scale-down.

    16

    The minimum time between scaling actions is five minutes. Scaling actions cannot occur if any of the instances are in a transitioning state.

    10. You can also specify the number of instances to delete or not use when your application is scaled down. A slider is used to specify the scaling increment. To increase the number of instances that are deleted or not used when your application is scaled down, drag the bar right. To decrease the number, drag the bar left.

    17

    11. Set the number of minutes to wait between the last scaling action and the next scale-down action. The last scaling action can be either scale-up or scale-down.

    18

    12. Click Save. The scaling action can take up to five minutes to finish.

    E. Scale linked resources

    Often when you scale a role, it’s beneficial to scale the database that the application is using also. If you link the database to the cloud service, you change the SQL Database edition and resize the database on the Scale page.

    1. In the Management Portal, click Cloud Services, and then click the name of the cloud service to open the dashboard.
    2. Click Scale.
    3. In the Linked Resources section, select the edition to use for the database.

    19

    4. Select the size of the database.
    5. Click Save to update the linked resources.

    F. Schedule the scaling of your application

    You can schedule automatic scaling of your application by configuring schedules for different times. The following options are available to you for automatic scaling:

    1. No schedule – This is the default option and enables your application to be automatically scaled the same way at all times.
    2. Day and night – This option enables you to specify scaling for specific times of day and night.

    Note: Schedules are currently not available for applications that use Virtual Machines.

    1. In the Management Portal, click Cloud Services, and then click the name of the cloud service to open the dashboard.
    2. Click Scale.
    3. On the Scale page, click set up schedule times.

    20

    4. Select the type of scaling schedule that you want to set up.
    5. Specify the times that the day starts and ends and set the time zone. For day and night scheduling, the times represent the start and end of the day with the remaining time representing night.
    6. Click the check mark at the bottom of the page to save the schedules.
    7. After you save the schedules, they will appear in the list. You can select the time schedule that you want to use and then modify your scale settings. The scale settings will only apply during the schedule that you selected. You can edit the schedules by clicking set up schedule times.

    G. Kentico Website Scalability and Performance

    Kentico performs extremely well on a very standard hardware configuration. Still, if you need more power and scaling up (adding more CPU and memory) isn’t enough; you can easily scale out and deploy Kentico in a webfarm. Kentico runs in a standard Windows Server web farm environment and it has built-in mechanisms for automatic synchronization of files and in-memory objects across servers. Based on our performance tests, adding a second web server doubles the overall performance.

    If the database server becomes a bottleneck, Kentico supports SQL Server Merge Replication which means you can also scale out your database servers. It means you can achieve virtually unlimited scalability with Kentico.

    Advanced Caching Options

    Kentico comes with granular cache settings that allow you to configure cache for files, web parts and pages. The full-page caching represents the most powerful option as it stores pages in memory and serves them without touching database or disk.

    1.1.2 How to deploy the core to Azure

    Deploying cloud service and kentico website over azure is very simple. You can follow following simple steps for deploying cloud service.

    1. Using Visual Studio 2012, Open Azure.Server solution. In the Server.DataAgents.Azure project, right click and select Publish

    21

    In a few seconds the Publish Web wizard appears. The wizard creates a new publish profile that contains settings such as the web site URL that Visual Studio needs in order to deploy your project to Azure. The profile is automatically saved so that later when you make changes to the project you can easily redeploy the project to the same site.

    2. Click Publish

    ^B369DD4B62C647AFA9197FFCA3B547048E7FA655B0C72D9EEB^pimgpsh_fullsize_distr


    1.2 Kentico

    The kentico documentation

    1.2.1 Azure support

    Kentico is supported as a standard, scalable web role. The following diagram illustrates the relations between the individual elements that together form Kentico CMS in the cloud environment. The different components depicted in the diagram are described in the text that follows.

    23

    The fact that Kentico CMS can run in multiple instances on Windows Azure creates the need for synchronization of data between the instances. The CMS handles this by considering each instance a web farm server. Unlike the traditional web farm comprising multiple physical servers, you don’t have to configure the web farm servers manually in the multiple-instance Azure environment. The only configuration that needs to be done is setting the number of instances in the service configuration file. Data is synchronized via web farm tasks, which are created and executed automatically.

    Storing session state

    Every complex web application needs to store information about its state, especially user session data. Since the Azure environment is dynamic and the application doesn’t reside constantly in one place, its state has to be stored separately.

    Kentico CMS is pre-configured to use the Windows Azure AppFabric caching service to take care of session information. This way, all instances of the application have access to their data, which keeps them synchronized.

    1.2.2 Social Media Autentication

    Kentico supports the following authentication providers:

    1. Windows Live ID
    2. OpenID > OpenID is an open, decentralized standard for authenticating users. It is currently being used by Google, Yahoo!, MySpace, Flickr and many more. Logon credentials used on all of these sites can be used to log on to your Kentico site. This follows OAUTH/2 protocol.
    3. Facebook Connect
    4. LinkedIn