Knowledge Base

Wiki: KKB Wiki

Anonymous — Fri, 24 May 2013 00:13:00 GMT

Wiki Page: Duplicate Domain GUID in Kaseya Discovery

Tim Cruz — Wed, 22 May 2013 15:36:00 GMT

KB#: KKB000990

QUESTION

Why am I getting error "Domain GUID reported by Netlogon is incorrect. Windows Active Directory issue must be fixed before this domain can be synced correctly"? Why are the Domain GUID's not matching correctly in Kaseya Discovery?

ANSWER

Kaseya Discovery checks for the domain GUID mismatch issue when it runs because it has been found to cause issues in the tracking of synced objects due to the fact that the domain GUID is incorrect in this case.

The cause is a bug in some OEM preinstalls of Windows Small Business Server (SBS). With this bug, the domain GUID entry in the registry entry "HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG" on the DCs are out of sync with the Active Directory database. To fix it, we recommend contacting Microsoft support as per the article link below. The correct domain GUIDs can be found in the error message in Discovery.

Please review the KB article link to fix this issue:
http://support.microsoft.com/default.aspx?scid=kb;en-us;909639&sd=rss&spid=3208

If any duplicate domains appear in Kaseya after the changes have been implemented on the Active Directory, please submit a ticket for further investigation.

APPLIES TO

Kaseya v6.3
Kaseya Discovery

Wiki Page: KLC unable to connect if DNS is unavailable on agent side

Dominic Walsh — Tue, 21 May 2013 09:51:00 GMT

KB# KKB001013

QUESTION

KLC unable to connect if DNS is unavailable on agent side

SYMPTOMS

- Agent check-in policy is configured with a DNS name as the "primary kserver" and an IP as the "secondary kserver"

- primary kserver address can no longer be resolved on the agent machine due to DNS failure

- agent continues to check in using the secondary kserver address, but Live Connect fails with the following error in the "Start KLC" procedure on the agent:

CAUSE

This problem is a combination of the amount of time the DNS look-up takes to fail and the wait time of the browser side. The relay attempts to connect on 3 different addresses (name/IP from System > Configure page, followed by primary and secondary kserver addresses from Agent > Check-in Control) but it tries to resolve any DNS names before attempting the connection. If the DNS lookup takes more than ~6 seconds, the connection will fail due to time-out on the browser side relay plug-in.

SOLUTION

The issue will be addressed in the next release of Kaseya (v6.4).

This workaround can be used to gain remote access to the agent and resolve any DNS issue: -

1) go to Agent > Check-in Control and temporarily change any DNS names for the affected agent(s) to the matching IP addresses - allow 1 or 2 minutes for the change to be applied to the agent

2) go to System > Configure page and temporarily change "external name / IP address of Server" from DNS name to IP address

3) try Live Connect to the agent again

4) once the DNS issue is resolved, reapply the desired configurations

APPLIES TO

Kaseya v6.3

Wiki Page: What are the different roles in the Kaseya Customer Portal and how do I create and manage my Kaseya Portal users?

Robert.Vambeck — Fri, 17 May 2013 16:52:00 GMT

KB#: KKB001011

QUESTION

What are the different roles in the Kaseya Customer Portal and how do I create and manage my Kaseya Portal users?

ANSWER

In order to manage the Kaseya Portal Users for your Kaseya Portal account, you need to have the Manager or Administrator role.

You can create and manage your organisation's users in the Kaseya Customer Portal (go to Kaseya Portal>My Account>My Portal Users)

Below is an explanation of the three Roles that are available for you to assign to your users within the Kaseya Customer Portal:

User:

Access to: Inbox, Create new tickets & View own tickets, Resources (Documentation, Knowledge etc), Direct access to Forums and Knowledge Base and Change Logon etc

Manager:

Same as User plus ‘My Portal Users’

Administrator:

Same as Manager plus ‘Credit Cards’, ‘Online Backup’, ‘Contract Summary’& ‘Account Aging’ Reports.

My Portal Users: Add, Edit, Delete, Enable, Disable and reset passwords for Users

Credit Cards: Add, Edit & Delete Credit Cards

Online Backup: Enable Cloud Storage for Kaseya Data Backup

Contract Summary: View Your Contract Summary

Account Aging: View Your Account Aging

Here is an image of the Kaseya Customer Portal while logged in with the Administrator Role:

APPLIES TO

This article refers to Kaseya On-Premise customers using the URL 'https://portal.kaseya.net' to log into the Customer Portal.

This article does not apply to SaaS E-Commerce customers, please see: http://community.kaseya.com/kb/w/wiki/64.aspx

Wiki Page: Kaseya Discovery (KDIS)

amado.hidalgo — Thu, 16 May 2013 17:10:00 GMT

Kaseya Discovery (KDIS)

This section will feature articles related to Kaseya Discovery module (available on VSA 6.3 and later).

Do not mistake it with the Kaseya Network Discovery module available on VSA 6.2 and earlier

KDIS Help

KDIS Release Notes

KDIS Quick Start Guide

KDIS User Guide

KDIS Forum

Wiki Page: Kaseya VNC components w/ Apple retina display agent machines

Dylan M. Lagi — Thu, 16 May 2013 03:30:00 GMT

KB #: KB0001010

Question: I have Apple retina-based (HiDPI) hardware. Will the Kaseya VNC components in the Remote Control tab, QuickView, and KLC work properly with them?

Answer:

At the moment, this is not possible due to a limitation with the x11vnc server software used by Kaseya on the Mac endpoints. Kaseya Engineering is presently working out a permanent solution to this as such. This KB Article will be updated appropriately once that fix is made available.

In the meantime, this manual workaround can be done on the retina display-based machines for usage with the present software:

1 - Ensure that the retina-based hardware has at least one user logged in.
2a - Run this command to enable non-retina/HiDPI resolutions avialable:

sudo defaults write /Library/Preferences/com.apple.windowserver DisplayResolutionEnabled -bool YES

2b - If running that command is not possible/has issues, download and use this app to make the non HiDPI/retina resolution options appear.
3 - Log off all users on the hardware and log back in - the non-retina resolutions option are available.
4 - Select the highest non-HiDPI display resolution available.
5 - Kaseya VNC usage to the endpoint will work properly from there.

Wiki Page: Troubleshooting failed patch installs and failed patch scans and incorrect data on Patch Status page

Brande Schweitzer — Mon, 13 May 2013 15:07:00 GMT

KB#: KKB000781

QUESTION:

Troubleshooting failed patch installs and failed patch scans

This article may be helpful in troubleshooting the following issues:

Patch Scan fails
Patch Status shows no patch data (only dashes) even after patch scan
Patch Status shows no missing patches but you believe there should be some
Patch Status numbers do not appear to be changing over time when you believe they should
Patches show as Missing or Failed in Kaseya but are installed on the endpoint
Patches show as Missing or Failed in Kaseya they are not missing according to Microsoft Update

In order to determine whether this article may be applicable to the conditions you are experiencing, view the Agent > Agent Logs > Agent Procedure Log (called a Script Log prior to Kaseya v6.1) for the specific endpoint.

Note: ensure you are reviewing the Agent Procedure log or the Script log, not the Agent log:

Locate the time of a recent Patch Scan. If you see a log entry indicating, “Patch Scan check failed using the primary data source…” this article may help to resolve the issue. If you cannot find a recent patch scan, go to Patch Management > Scan Machine, select the endpoint, and click “Run Now” to force a new Patch Scan. Once the patch scan completes, review the logs. If you do not find this error in the Agent Procedure log, this article does not apply.

ANSWER:

Patch Scan can fail to use the primary source for a number of reasons. To explain this, it is necessary to first address the differences between the primary and alternate data sources.

The Primary Data Source for patch management is the Microsoft Update Catalog. Kaseya leverages the Windows Update Agent (wua.api) to check the Microsoft Update Catalog (MUC) for all patches currently available and to determine which of those patches are applicable to the endpoint. The Kaseya UI allows you to manage which patches should be installed via Patch Policy, but Kaseya is not "deciding" which patch(es) apply to a specific endpoint.

When the Primary Data Source is not available, the patch scan will defer to an alternate source. This source, Windows Server Update Service (WSUS which, despite its name, is not applicable only to servers) is a .cab file that is stored locally on the endpoint. As there is a file size limit to WSUSscn2.cab, it contains only an extremely limited number of patches - only current, active Service Packs, Security Updates, and Update Rollups. For example, where the MUC might contain 10,000, the .cab file might contain only 100. Of those, only one might potentially apply to the endpoint and if that patch is already installed (Windows 7 SP1, for example), then patch scan would not report any needed patches.

The Agent Procedure log will contain an error code indicating why the scan failed to use the primary data source. This error is Microsoft-generated and will be formatted similar to 0x00000000. You can often find some general information about the error code by searching the web. Technet can be a good place to begin, and this site is also a good reference.

The failure of the primary data source is generally caused by only a handful of things: firewall and/or proxy restriction, the Windows/MS update service being disabled by Group Policy (GPO), and/or the Background Intelligent Transfer Service (BITS) not being enabled on the endpoint. There are some other, less common issues the can cause this, but these three contribute to more than 95% of the failures of the primary data source.

1. Ensure the five websites necessary for patching are not disallowed by Firewall, Proxy, web filter or other security services (allow anonymous browse access to these sites). The five sites are:

· update.microsoft.com

· download.microsoft.com

· download.windowsupdate.com

· www.windowsupdate.com

· vsaupdate.kaseya.net

If you do not have direct access to the firewall/proxy configuration, you can verify this most of the time by logging into the endpoint using the account defined in Agent > Set Credential. Using Internet Explorer (the MS sites require IE), browse to each of the websites listed.

2. Verify MS/Windows Update is not disallowed by GPO for the endpoint or the user. Because Kaseya leverages the wua.api to compare the endpoint to the MUC, disabling the service by GPO will cause the scan to fail using the primary source. If you are unfamiliar with verifying GPO settings, please refer to http://support.microsoft.com/kb/328010 for detailed information regarding GPO settings.

3. BITS is a built-in Windows service that can be managed in the same way as other Windows services (generally accessible by right-clicking "Computer" and selecting "Manage"). Ensure the service is enabled and set to start automatically. You can find general information regarding BITS here: http://en.wikipedia.org/wiki/Background_Intelligent_Transfer_Service

4. If the patch scan error being thrown is 0x80248014 and the endpoints in question are Windows7/Server2003 or earlier, stop the Windows Update or Automatic Update SERVICE, delete c:\Windows\SoftwareDistribution, and then start the Windows Update/Automatic Update service. This error often indicates that the SoftwareDistribution folder (Microsoft's temporary patch folder, similar to Temporary Internet Files folder for Internet Explorer) has become corrupt or unreadable to WUA. The folder and any necessary contents will be recreated automatically by the OS. If you choose, you can rename the folder instead. Either way, you must stop the WUA service before making a change to the folder and restart the service after the change is complete. The windows service name is wuauserv and can be called via command line using "net stop wuauserv" and "net start wuauserv". Please refer to Microsoft documentation for further information.

If the endpoints in question are Windows8/Server2012, this is caused by Microsoft's new requirement for these products to manually opt-in to the Microsoft Update service (which is needed to run the scan against the online catalog/primary data source). Microsoft provides details here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa826676(v=vs.85).aspx. Kaseya is preparing a hotfix address this. While no admin action is required at this time, VSA admins can opt to create a custom script to deploy to end machines or request end users opt into the service as a work-around until the hotfix is released.

Please check these settings, adjust as necessary, and re-run patch scan. If the scan continues to report the failure of the primary source, research the error code via a web search. Three helpful sites are:

If you are able to determine the meaning of the error, search the web for possible fixes. If you are unable to determine the error, or if the steps you find do not resolve the issue, please open a ticket with Kaseya Support. We will attempt to help resolve the Windows Update error.

ADDITIONAL INFORMATION:

You can sometimes find additional information regarding patch failures in the c:\Windows\WindowsUpdate.log file and/or any KB Log files that might have generated. You can access the available files either on the endpoint or within the VSA by navigating to Agent Procedures > File Transfer > Get File and selecting the endpoint.

APPLIES TO:

Patch Management

VSA (all versions)

Wiki Page: *Kaseya Mac Agent - Interim build release notes

Dylan M. Lagi — Fri, 10 May 2013 13:57:00 GMT

KB Article #: KKB000769

Click here to load the contents of this page in a new window.

Wiki Page: *Kaseya Windows Agent - Interim build release notes

amado.hidalgo — Fri, 10 May 2013 11:32:00 GMT

KB Article #: KKB000767

Click here to load the contents of this page in a new window.

Wiki Page: *Kaseya Linux Agent - Interim build release notes

amado.hidalgo — Fri, 10 May 2013 11:32:00 GMT

KB Article #: KKB000768

Click here to load the contents of this page in a new window.

Wiki Page: How do alert times/tags work on SaaS?

Nicolas — Thu, 09 May 2013 16:25:00 GMT

KB# KKB001006

QUESTION

How do alert times work on the SaaS Servers? 

ANSWER

There are several times that are shown from the VSA and the Alerts they create. 

Times are often wanted in various combinations, one time across the board, or several time zones at once. This article will clarify how the times will appear in the VSA and how they will appear inside your email(s) / ticket(s). 

The following example screenshots in the VSA are set with a time zone offset of - 4. This is configured in System > Preferences. 

 

The time inside the alerts depend on the data keys being implemented in the "Format Email" option for each alert respectively. 



As the SaaS servers are mostly located in our United Kingdom datacenters, they will be set to GMT time. 

Certain data keys are hardcoded to the time zone of the server in GMT Time. (E.g: <at>, <et>) When using the common <at> data key, this will implement the GMT time of the server. Therefore, any alert using <at> in the "Format Email" section will send out the alarm in GMT time. The <ata> data key will implement the time of the agent that triggered the alarm. The <et> data key will implement UTC time. 

Here are some examples 

Fixed Alert triggered using <at>: 

 


Here is an example using <ata> data key which will show the alarm time from the agent time. In this case - the agent time is in EST Time and the VSA Time is in EST Time as well: 




This applies to following fixed alerts: Agent Status, Get Files, Protection Violation, System alerts. 

Event Log Alerts using <at> and <ata> data keys examples: 

<at> data key example in a event log alert: 

 


<ata> data key example in a event log alert: 

 

Monitor Set Alert example using <at> and <ata> data keys: 

Example <at> data key implemented in a monitor set: 

 


Example <ata> data key implemented in a monitor set: 




Additionally, the format email’s can be configured in any fashion and implement several data keys at once. 

Here is an example using the <at>, <qt>, <qta>, and <ata> data keys.




APPLIES TO
Kaseya VSA version 6.3. SaaS Servers

Wiki Page: Adobe Flash support in KSDU/NinitePro

Tim Cruz — Wed, 08 May 2013 11:13:00 GMT

KB# KKB001007

QUESTION

Ninite is no longer providing support to Adobe Flash due to the request of Adobe. Will this affect my Adobe Flash updates in KSDU?
 

ANSWER

No. KSDU utilizes NinitePro. Ninite has stopped support of Adobe Flash ONLY within their free version of their product. 
Support for Adobe Flash will continue through the NinitePro application and thus Kaseya will continue to support Adobe Flash in the KSDU catalog.
 

APPLIES TO

Kaseya Software Deployment and Update

Wiki Page: How do alert times work on SaaS Servers?

Sajjad Zaidi — Tue, 07 May 2013 18:05:00 GMT

Question:

How do alert times work on SaaS Servers?

Answer:

There are several times that are shown from the VSA and the Alerts they create.

Times are often wanted in various combinations, one time across the board, or several time zones at once.

This will clarify how the times will appear in the VSA and how they will appear inside your email(s)/ticket(s).

All of the following screen shots in the VSA are set with a time zone offset of - 4 in System > Preferences on the SaaS11.kaseya.net server.

The time inside the alerts depend on the data keys being implemented in the "Format Email" option for each alert respectively.

As the SaaS servers are mostly located in the UK they will be set to GMT time.

Certain data keys are hardcoded to the time zone of the server in GMT Time. (EX: <at>, <et>)

When using the common <at> data key - this will implement the GMT time of the server.

Therefore, any alert using <at> in the "Format Email" section will send out the alarm in GMT time.

The <ata> data key will implement the time of the agent that triggered the alarm.

The <et> data key will implement UTC time.

Here are some examples:

Fixed Alert triggered using <at>:

Here is an example using <ata> data key which will show the alarm time from the agent time.

In this case - the agent time is in EST Time and the VSA Time is in EST Time as well:

This applies to following fixed alerts:

Agent Status, Get Files, Protection Violation, System alerts.

Event Log Alerts using <at> and <ata> data keys examples:

<at> data key example in a event log alert:

<ata> data key example in a event log alert:

Monitor Set Alert example using <at> and <ata> data keys:

Example <at> data key implemented in a monitor set:

Example <ata> data key implemented in a monitor set:

Additionally, the format email’s can be configured in any fashion and implement several data keys at once.

Here is an example using the <at>, <qt>, <qta>, and <ata> data keys:

Applies to:

Kaseya Version 6.3

Wiki Page: Eventlog Collection Dependency for alerting in V6.3

Sajjad Zaidi — Tue, 07 May 2013 16:15:00 GMT

Eventlog collection in 6.3

A recent hotfix has introduced a new feature where dependency on eventlog collection to invoke eventlog alerts has been removed and alerts can function without it. Please note that this feature does not disable the eventlog collection feature at all and it can be activated from Agent Tab > Event Log Settings.

What is required to activate this feature?

1 - Get latest hotfixes in your VSA

Note - SaaS VSA users already have them

2 - The Windows Agent must be up to date at Agent version 6.3.0.7 or above.

Note - If under 6307 on your Windows agent, choose to force update it via the Agent > Update Agent page.

Eventlog alert Behavior in version Kaseya Version 6.2 (Previous method)

VSA automatically collects Eventlog Level and Type when corresponding eventID is set for alerting.

Applies to:

Kaseya Version 6.3

Wiki Page: Copying from the Content Pack's System Cabinet

Brande Schweitzer — Tue, 07 May 2013 15:15:00 GMT

System Content is provided by Kaseya as a set of best practices. Content within the System cabinets should not be edited. These cabinets may be locked down to prevent editing of the content. Content can be copied from the System cabinet for customization. Please review this article for information regarding the content pack. Details on copying from the System cabinet are available at the end of this article.

The Systems Management utility is a set of canned content including computer management policies, monitor sets, views, patch policies, and agent procedures. To download this content from Kaseya, VSA admins will need to configure Systems Management for at least one organization or machine group. This content is available to systems running 6.3 and later. Views that are part of the Content Pack will be named beginning with "zz[SYS]". Within various modules, the Content pack information will be available in the System cabinet:

Enabling Systems Management

Navigate to System > Manage and select one machine group or organization
Click the Systems Management tab
Click Configure
Step through the wizard to enable the preferred options
Click Finish

If not already available on the system, the Content Pack will be automatically downloaded from Kaseya to your VSA. A message will be available in your Info Center inbox once the content download is complete.

The content pack is a set of best practices. Policy Management policies will be automatically assigned to machines in the selected organizations based on these best practices. To learn more about the Systems Management tool, please visit http://help.kaseya.com/WebHelp/EN/SSP/1000000/index.htm#11252.htm.

Editing System Content Policies

Policy Management system content policies should not be edited. To customize a system policy, copy the policy to the Private cabinet. Policies can be copied individually OR an entire folder structure can be copied. Once the policies have been copied to the system cabinet, edit the policies as necessary and assign the new policy to the appropriate machines and/or organizations.

Copying System Content Policies

Navigate to Policy Management > Policies
Expand the System cabinet
Identify the individual policy OR folder structure to be copied
Press and hold the Crtl button on the keyboard
Select the policy/folder to be copied
While holding Crtl, drag the policy/folder to the Policies cabinet
Release the policy/folder into the appropriate folder within the Policies cabinet

Note: You must press/hold the Crtl button before beginning the drag/drop of the policy or folder

Once the policy is copied, it may be edited and applied to any machine, machine group, organization, and/or to the global level.

For additional information on using the Systems Management tool, creating, assigning, and editing policies, and for details on policy precedence, please review the Policy Management TechJam presentation available at http://community.kaseya.com/resources/m/techjams/83216.aspx

Wiki Page: *Unable to expand file selection list from IE9 and above

Dominic Walsh — Tue, 07 May 2013 08:31:00 GMT

KKB000896

SYMPTOM

Unable to expand the file selection list using Internet Explorer v9 or higher. This affects the following functions: -

Recovery > Restore
Recovery > Manage
Backup > Schedule

Other browsers (IE8, Firefox, Chrome) are not affected.

CAUSE

There is a compatibility issue between IE9 and the current Java framework used for the Kaseya user interface.

SOLUTION

The problem will be resolved in the next release of Kaseya Data Backup. In the meantime, the workaround is to use one of the other supported browsers mentioned above.

APPLIES TO

Kaseya Data Backup (KDB) v2.0

Kaseya VSA framework (all versions)

Internet Explorer v9 and above

Wiki Page: Support for non-iOS & Android Devices

chris.sheehan — Fri, 03 May 2013 10:54:00 GMT

KB# - KKB000836

Question - Are there plans to support Mobile OS's other than iOS, Android & Blackberry in KMDM in the future?

Answer -

Kaseya is of course interested in expanding its mobile OS platform support in KMDM. Should you have a specific mobile OS type you would like to have supported that presently is not, simply raise a ticket noting this information at https://portal.kaseya.com.

Wiki Page: When should the “Enable VSS support” option be enabled?

amado.hidalgo — Thu, 02 May 2013 12:55:00 GMT

KB#: KKB000532

QUESTION

When should “Enable VSS support” option be enabled in Backup > Schedule Volumes or Backup > Schedule Folder page?

ANSWER

About VSS

Shadow Copy is a is a technology included in Microsoft Windows that allows taking manual or automatic backup copies or snapshots of data, even if it has a lock, on a specific volume at a specific point in time over regular intervals. It is implemented as a Windows service called the Volume Shadow Copy service (VSS).

Snapshots have two primary purposes: -

1) allow the creation of consistent backups of a volume, ensuring that the contents cannot change while the backup is being made; and they avoid problems with file locking

2) by creating a read-only copy of the volume, backup programs are able to access every file without interfering with other programs writing to those same files.

Applications can provide specific support for VSS through VSS writers which control how data is set to a consistent state at the beginning of a VSS operation and maintain that consistency throughout the process, among other functions. Windows applications and services that support VSS include Hyper-V, Virtual Server, Active Directory, SQL Server, Exchange Server, SharePoint and some third-party solutions such as Oracle.

Kaseya Backup (Acronis) VSS implementation

Older versions of Acronis software had an Acronis proprietary VSS provider which was unreliable in some environments. Kaseya Backup v3.2 and above use Windows native VSS provider on clients with an Acronis build that supports it (Acronis v9.7 and above).

Currently VSS can only be enabled on Windows Server 2003 and 2008. In the upcoming new release (v5.0) support will be added for workstation OS’s as well as the latest Windows operating systems (Windows 8 and 2012).

When to use VSS option

VSS should be enabled if: -

1) you need to ensure a VSS compliant application such as those listed above are backed up in a clean and consistent state. If you are not sure whether an application is VSS compliant, contact the software vendor.

2) you are taking a folder based backup of files which may be in use or locked at the time of the backup

Do VSS backups take applications or databases offline?

No, but applications that have VSS writers will freeze write I/O requests for a maximum of 60 seconds during snapshot creation process. This may affect performance if the backup is taken at a busy time.

Can I restore a database from a non-VSS backup?

Yes, but it may have been backed up in a “crash consistent” state with incomplete I/O operations or data corruption. Some additional steps may be needed to recover to a usable state.

Are database transaction logs flushed to disk?

How a database is prepared for VSS snapshot is the responsibility of the application’s VSS writer. Contact the application vendor for details.

FURTHER INFORMATION

A detailed description of the VSS process can be found here - http://technet.microsoft.com/en-us/library/cc757854(WS.10).aspx

APPLIES TO
Kaseya Backup (KBU) - all versions

Wiki Page: How can I view/print current and past invoices?

amado.hidalgo — Thu, 02 May 2013 12:33:00 GMT

KB#: KKB000317

QUESTION

How can I view/print current and past invoices?

ANSWER

See http://community.kaseya.com/kb/w/wiki/794.aspx

APPLIES TO:

IT Center, SaaS ecommerce

Wiki Page: How do I see my current or past invoices?

amado.hidalgo — Thu, 02 May 2013 12:32:00 GMT

KB#: KKB000317

· QUESTION
How do I see my current or past invoices?

· ANSWER

Navigate to Kaseya product -> Kaseya Portal -> My Account -> Account Information -> Invoices Tab -> Invoice History Tab.
You will be able to save or print invoices here.

· APPLIES TO

IT Center, SaaS ecommerce