Xf- Adesk 2013 X64 .exe
Jahed Stetter
Why can't I upload BIM 360 Docs ? It says "this type of file is not supported".
It was possible to do so in BIM 360 (the old A360), why isn't it now ? This is really frustrating and complicating things for our company workflow.
First the universal sharing link and now .exe files not being able to upload ? How are we supposed to use this platform when the old one (A360) was much better ?
EDIT : I found a workaround : renaming the file "Enscape (rename .txt into .exe).txt". It's not very professional but at least it works for the mean time...
Sharing a bit more info on why we specifically exclude .exe files from our system. There are certain file type (like .exe) which can potentially include malware and provide a security risk not only for you but for other customers using BIM 360. We take security very seriously and are constantly taking measure to ensure our customers data is protected. I apologize for the inconvenience of not being able to upload these file types to BIM 360, I hope this rational makes sense.
For .exe files maybe a smart solution would be that only the administrator of the project can upload .exe files.
We used A360 for a couple of years before this and never had any problems whilst stocking .exe files.
Currently the only solution for us is to changed the format of the file to .txt and add "change .txt to .exe" in the name of the file. It's not handy at all. You can still put .exe files this way. It just makes life a bit more frustating for everyone.
I understand, we have evolved our security practices over the last few years and this is a case we chose to be a bit more strict compared to A360. I totally understand this is create some level of discomfort but I hope you understand that the security of your data and the data of our other customers is our top most priority and in some cases where no other option is available, we might need to prioritize the security controls we have in place over enabling a new feature.
I tried to use 'nexe' module and build executable file. With this method, I need to specify index.js file ("an entry point") and define a 'nexe.config.js' file. I used the entry point start.js.
Eventually, I managed to create an exe file - and when I run it from the command line, I get an error
I'm not sure how nexe works exactly but please note that the sample app expects input parameters such as FORGE_CLIENT_ID or FORGE_CLIENT_SECRET to be provided as environment variables.
If that doesn't work, try hard-coding the input parameters directly into the config.js file (replacing any of the process.env.* references), and then bundle everything into an *.exe file. This is just for debugging purposes, though! You shouldn't share your credentials with anyone, not even inside an *.exe file. So as an alternative I'd suggest that you update the sample app to read the input parameters from somewhere else, perhaps from a local file.
after trying a lot of solutions, i got to the conclusion that the reason that nothing happened was that the oathantication files ( with the clint_id and clint_password) was not embedded in the .exe file.the way to include those files with the nexe module is to use the flag -r "Foldername/subfoldername/filename.js".
Our company uses PowerMill in various sites. While Autodesk is nice enough to provide a deployment package with an installation script, I'm struggling to get it working with the KACE through either managed installation or running a script.
With the Managed installation, I have it assigned to the software inventory that gets installed. For example, Autodesk PowerMill Standard 2025 (25.0.1). I've tried associating the .bat file that autodesk creates (which works fine if you run it on the target system manually). Pretty much from the install share, it launches:
I've tried various was of invoking this through the MI portion. Running the .bat file form Autodesk through the $(KACE_DEPENDENCY_DIR) (which does work if I manually trigger it), doing a default override with the batch file on the share, doing a default override with the command line from the batch file (that is running the full [Share]\Installer.exe -i deploy --offline_mode etc. Nothing seems to work.
I even tried running it as a script, both by having the KACE copy the script locally, and run it direct from the share, running it as system, running it with admin credentials...nothing seems to want it to trigger.
For some reason, it just seems to be Autodesk products. I've tried with DWG TrueView and Moldflow Communicator (both Autodesk products) and similar results. Other CAD/CAM software we have in our environment seem to have no issues being push-deployed through the KACE.
Has anyone else ever run into issues trying to install products with a batch file? The KACE does have access to the installer directories (like I said, other products seem to deploy without any problems).
Hi @bgiroux,
We've deploy different Autodesk products from our K1000. However, our approach is local installation rather than network share and our online KACE script runs as system.
Uploaded each package created from Autodesk custom deployment module. Made modifications to the generated batch file in root folder & .\image\Collection.xml. Works perfectly.
I think MI runs as system account, hence it will fail as you are attempting to access a network resource. Online script should do the trick.
Create an online KACE script, supply proper credentials, Run a batch file & input "\\share\Installer.exe" -i deploy --offline_mode -q -o "\\share\Configurationfile.xml"
AcDeltree.exe is a software program developed by Autodesk, Inc that is used to remove Autodesk components and files from a system. This tool is often used when uninstalling Autodesk software to ensure that all associated files and components are completely removed from the computer.
How do we know? Our SpyShelter cybersecurity labs focuses on monitoring different types of Windows PC executables and their behaviors for our popular SpyShelter Antispyware software. Learn more about us, and how our cybersecurity team studies Windows PC executables/processes.
The publisher of an executable is the entity responsible for its distribution and authenticity. Most processes/executables on your PC should be signed. The signature on the executable should have been verified through a third party whose job it is to make sure the entity is who it says it is. Find an unsigned executable? You should consider scanning any completely unsigned .exe on your PC.
I'm far from the first person to make a light change color based on the status of your Skype for Business account, but I think I'm the first person to write a tutorial using addressable WS2812 LED strips. I prefer these lights because with minimal hardware (the strip, power/data/ground) you can have a large amount of LED lights. You don't have to solder any resistors, power transistors, or even separate wires for Red/Green/Blue. They can do far more than display the single static color used in this project.
I basically took their project and added more features. There's another Instructable here that uses a different monitoring program and has fading light functions. I think the animations are cool, but decided that for full desk underglow like mine that fading lights would be too distracting for everyone else in the office.
WS2811 is the name of a cheap and common type of addressable LED strip. Each light on the strip is an RGB LED and you can control the color of each one individually. WS2811 actually isn't the LED - it's an integrated circuit chip that uses a certain data protocol. [datasheet] Every WS2811 chip boosts the data signal up to the operating voltage, so you don't have to worry about signal degradation. You can drive over 1000 LEDS at 20fps with the WS2811 protocol.
I prefer to use these LED strips because the wiring is dead simple for them. Give it power, ground, and data. You don't need to use power transistors like you do with standard 4-wire RGB strips, and you don't need to run a wire to the microcontroller for each light or each channel. You just give it power and a data signal and you're good to go.
The downside of these strips is that they need a microcontroller giving them a signal when they turn on, you can't just give it power and no signal and expect it to work. After you write a color pattern to it the strip will hold that pattern until you update it or it loses power. Another downside is that their timing pattern is very precise and picky, so you might have to disable interrupts on your microcontroller so that the FastLED library has priority when writing to the LEDs. This can result in wifi instability and requires some special code structure.
ONLY TIE THE GROUND TOGETHER BETWEEN THE ARDUINO AND YOUR DC POWER SUPPLY. DO NOT TIE THE +5V or +12V TOGETHER. There should only be two wires going from the microcontroller to your LED strip: Data, and Gnd.
First cut out the cardboard or foam board to mount the light strips on. It's easier to have the strips mounted in place when soldering the strips than using a third-hand to hold the strips in the air.
Look on the strips and there should be an arrow every few lights, or each side will be labelled "DO" or "DI" - DI is data In, DO is data Out. You need to wire it [Arduino]-->[DI]----LED----[DO][DI]------LED-----[DO][DI] etc. Basically data line from arduino goes to the DI pin. If it has arrows, make sure your data "flows" in the direction of the arrows.
Personally I've found that it's easier to solder the power and ground to the middle of the strip instead of the input pin - it really doesn't matter where you put it because the +/- are all connected together as one big rail. So you'll see in one of the pictures that for going from one LED strip to the other I only soldered a connector for the Data line - this works because I gave +12V and Gnd on both strips. One way or another you need all of your Ground wires to be tied together throughout the project.
b1e95dc632