# Configure License Server Validation

License Server Validation lets a protected application ask the website whether a license is still accepted. A central change to blocking, customer state or expiration can therefore take effect without distributing a new file.

You do not need to program a web service. Create the website, select the Project and enter the shown service URL in IntelliLock.

Create a Customer, Product and central License. The License must select the customer. Select a product whenever the entitlement is product-specific.

The product should select the .ilproj Project used to protect the application. If the license has no product or the product has no project, the default Project is used.

Open Integrations → Service Endpoints. Under Existing root endpoints, select the project for ValidationService and save the root assignments.

The standard URLs are:

https://licenses.example.com/ValidationService.ashx
https://licenses.example.com/ValidationService.asmx

The page deliberately shows both URL forms. They provide the same Validation function and use the same Project assignment:

• protected .NET Framework applications use .asmx;
• protected .NET 5 and later applications use .ashx.

You may enter either displayed URL in the IntelliLock project. At runtime, IntelliLock automatically selects the matching suffix for the protected application. You do not need separate license files or endpoint profiles for the two forms.

For multiple products or projects, create a virtual endpoint such as:

https://licenses.example.com/services/enterprise/ValidationService.ashx

1. Open the same .ilproj used to protect the application.
2. In License Generator, enable Force License Server Validation.
3. Open its setup dialog.
4. Select the global/server option.
5. Enter the chosen ValidationService URL.
6. Protect the application again after changing embedded validation settings.

Use HTTPS in production. The service URL is contacted by the protected customer application and must be reachable from that customer's network.

Return to Licenses, save the central record, then choose Create License. The generated file includes LicenseID plus useful customer, product, project and validity information.

Test the protected application with this file before sending it to a customer. Then block and unblock the test License once to confirm that online validation uses the intended server record.

New files containing LicenseID are checked against exactly that License record:

• the record must exist;
• its customer and product must be consistent with the file;
• it must belong to the endpoint project;
• the customer must be usable;
• the License must not be blocked; and
• its creation/expiration rules must accept the current date, unless NeverExpires is selected.

Existing deployed files remain compatible:

1. A historical LicenseTrackID is first treated as an exact current LicenseID.
2. If no usable ID exists, the service resolves the customer from legacy company, first-name and last-name data.
3. It then looks for a matching valid License, considering the product when it is available.

This fallback is necessarily less precise than a stable LicenseID. Reissue files with current IDs when practical.

Check the following in order:

1. The client can reach the exact URL and HTTPS certificate chain.
2. The endpoint is active and ValidationService is enabled.
3. The assigned .ilproj exists safely inside App_Data.
4. The central License has a Customer.
5. LicenseID, CustomerID and ProductID in the file match the database.
6. The endpoint project matches the Product/License project.
7. The License is not blocked or expired.
8. For a legacy file, customer names and company match a usable record.
9. Rate limiting is not returning HTTP 429.

System Health detects missing project files and broken relationships. The License Tracker can optionally record rejected Validation requests and their short reason.

The dashboard first shows a short warning:

Open Review details to see the affected records and the related management page: