Prerequisites
A server meeting LDAWP's system requirements.
An Administrator-type Windows user account, used to install and activate DigiPara Liftdesigner and to install and configure LDAWP.
A decision on which service-account model to use for running LDAWP: a full Administrative Account, or a more restricted Non-Interactive Service Account (recommended for secure server environments).
Enable the required server roles and features
Launch Server Manager.
Log in with the Administrator-type account to launch the manager.Set the server role.
Open the Manage menu in the top-right corner and select Add Roles and Features.Enable the Web Server (IIS) role.
In the installation wizard, go to Server Roles and make sure the Web Server (IIS) role is enabled, then click Next.Configure the .NET Framework 4.8 Features.
In the Features section select:ASP.NET 4.8
WCF Services > HTTP Activation
Configure the Web Server Role (IIS).
Under Role Services, verify the following are configured:
- Common HTTP Features: Default Document, Directory Browsing, HTTP Errors, Static Content.
- Health and Diagnostics: HTTP Logging.
- Performance: Static Content Compression.
- Security: Request Filtering, Basic Authentication, Centralized SSL Certificate Support.
- Application Development: .NET Extensibility 4.X, ASP.NET 4.X, ISAPI Extensions, ISAPI Filters.
- Management Tools: IIS Management Console, IIS 6 Management Compatibility (all options), IIS Management Scripts and Tools, Management Service.Click Install to apply the configuration.
Restart the system if prompted.Run the Windows Update.
Once all requirements are installed, search for updates to bring the server's security patches and stability fixes up to date.
Create the LDAWPServiceUser account (optional)
Choose one of the two account models:
Option A — Administrative Account
The account gets full Administrator privileges. This maximizes compatibility but is a less restrictive security model.
Create a new user in Windows following your organization's standard procedure.
Name it LDAWPServiceUser and add it to the Administrators group.
Set a password of your choosing.
Option B — Non-Interactive Service Account
The account gets standard user permissions and is prevented from being used for interactive desktop sessions — the preferred model for secure server environments.
In Local Users and Groups, open the Groups folder, choose Action > New Group, and name it NonInteractive.
Open Local Security Policy, navigate to Local Policies > User Rights Assignment, and configure each of these three policies (double-click each, click Add User or Group, select Groups as the object type, enter NonInteractive, and click OK):
Deny log on locally
Deny log on through Remote Desktop Service
Log on as a service
Create the LDAWPServiceUser account (same as Option A) and add it as a member of the NonInteractive group.
NOTE: When adding the group, make sure the object type is set to Groups, not Users.
Create the LDAWPServiceUser profile directory
Windows only creates a user account's profile directory on that account's first interactive logon — so how you create it depends on which account model you chose above.
Administrative Account: Log in once, interactively, as the new LDAWPServiceUser to create its profile directory.
Non-Interactive Service Account: Because the account's policy denies interactive logon, that first-logon trick can't happen. Instead, run the
New-UserProfile.ps1script to create the profile directory: it calls the WindowsCreateProfileAPI (userenv.dll) directly, so the folder, its registry entry (ProfileList), and its ACLs are all created correctly without an interactive logon.Run the script from an elevated (Administrator) console.
The LDAWPServiceUser account must already exist before running it.
<#
.SYNOPSIS
Creates the user profile directory (C:\Users\<User>) for an existing
Windows account WITHOUT requiring an interactive logon.
.PARAMETER UserName
The account's logon name. Use DOMAIN\User for domain accounts, or just
the user name for local accounts.
.EXAMPLE
.\New-UserProfile.ps1 -UserName "LDAWPServiceUser"
.NOTES
- Must be run from an elevated (Administrator) console.
- The user account must already exist.
#>
param(
[Parameter(Mandatory = $true)]
[string]$UserName
)
# --- Check for administrator privileges ---
$isAdmin = ([Security.Principal.WindowsPrincipal] `
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if (-not $isAdmin) {
Write-Error "Please run this script from an elevated (Administrator) console."
exit 1
}
# --- Resolve the user's SID ---
try {
$ntAccount = New-Object System.Security.Principal.NTAccount($UserName)
$sid = $ntAccount.Translate([System.Security.Principal.SecurityIdentifier]).Value
}
catch {
Write-Error "Could not resolve the SID for '$UserName'. Does the account exist? ($_)"
exit 1
}
Write-Host "User : $UserName"
Write-Host "SID : $sid"
# --- Import CreateProfile via P/Invoke (only once per session) ---
if (-not ([System.Management.Automation.PSTypeName]'Win32.ProfileApi').Type) {
$signature = @'
[DllImport("userenv.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern int CreateProfile(
[MarshalAs(UnmanagedType.LPWStr)] string pszUserSid,
[MarshalAs(UnmanagedType.LPWStr)] string pszUserName,
[Out][MarshalAs(UnmanagedType.LPWStr)] System.Text.StringBuilder pszProfilePath,
uint cchProfilePath);
'@
Add-Type -MemberDefinition $signature -Name "ProfileApi" -Namespace "Win32"
}
# --- Create the profile ---
$accountName = $UserName.Split('\')[-1]
$pathBuffer = New-Object System.Text.StringBuilder(260) # MAX_PATH
$result = [Win32.ProfileApi]::CreateProfile($sid, $accountName, $pathBuffer, $pathBuffer.Capacity)
# --- Evaluate the result ---
if ($result -eq 0) {
Write-Host "Profile created successfully:" -ForegroundColor Green
Write-Host " $($pathBuffer.ToString())"
}
else {
$win32 = $result -band 0xFFFF
if ($win32 -eq 183) { # ERROR_ALREADY_EXISTS
Write-Warning "A profile for '$UserName' already exists - nothing to do."
}
else {
$hex = "0x{0:X8}" -f $result
Write-Error "CreateProfile failed (HRESULT $hex, Win32 error $win32)."
exit 1
}
}
Either way, check whether the profile directory now exists under Settings → System → Advanced System Settings → User Profiles.
Verify the LDAWPServiceUser configuration
Go to Control Panel > System > Advanced system settings.
Under the Advanced tab, click Settings in the User Profiles section.
Confirm LDAWPServiceUser appears in the list of user accounts. If it does not, repeat the account-creation steps above.
Result: The server has the Web Server (IIS) role and the required .NET Framework 4.8 features enabled, and a verified LDAWPServiceUser account exists — with its profile directory created — ready to be used when installing and configuring LDAWP.




